# Gavin Andresen's posts at bitointalk.org
# Last edited on 2016-05-11 02:00:01 by stolfilocal
# 
@chars null   {}
@chars blank  {}
@chars alpha  {ABCDEFGHIJKLMNOPQRSTUVWXYZ}
@chars alpha  {abcdefghijklmnopqrstuvwxyz}
@chars alpha  {'~°}
@chars symbol {0123456789&*/=$£_+%\^}
@chars punct  {.,!?():;-"}
#
# SOURCE AND CREDITS
#
#   This is a collection of all the posts by Gavin Andresen 
#   that were publicly accessible at bitcointalk.org on 2016-05-08.
#
#   The posts were heavily reformatted and pruned for statistical 
#   purposes by J. Stolfi.  Therefore, DO NOT USE THIS FILE
#   AS A REFERENCE FOR ITS SEMANTIC CONTENTS. Refer instead
#   to the original posts on bitcointalk.org
# 
#   The posts were fetched from the site 
#   "https://bitcointalk.org/index.php?${args}"
#   where ${args} is
#   "action=profile;u=${usernum};sa=showPosts;start=${sk}",
#   ${usernum} is 224 for Gavin, and ${sk} is the number of 
#   posts to skip (20 per page).
#
#   The reformattin included removing all
#   quoted texts, code fragmenst, URLs, images, and 
#   HTML markup.  Some of the omitted material
#   was replaced by generic tokens like @s{quotedtext}.
#
#   This file has 2264 posts, spanning from 2010-05-29 19:16:36
#   to 2015-04-06 22:30:39 (UTC).
# 
# LANGUAGE, SPELLING AND ENCODING
#   
#   The language is mostly American English prose in ASCII encoding.
#  
#   ??? CHECK ???
#   except that "~" is used for hyphen,
#   to distinguish it from punctuation dashes, and "°" for 
#   period of abbreviation, to distinguish it from final stop. 
# 
#   Indented text is marked with "{»}" comments. Significant line
#   breaks or ends (in tables, indices, verse, etc.) are marked with "÷", and
#   paragraph breaks with "=".
#
# DOCUMENT STRUCTURE  
#
#
# CHANGES FOR THIS VERSION
#    
#   The source file was extensively reformatted for statistical 
#   purposes by J. Stolfi.
#
#   Hyphens were replaced by "~".
#   
#   Abbreviation periods were replaced by "°" or "°."
#   (or, in two cases, by "°,").
#

@section 1 {b}

# ----------------------------------------------------------------------
@section 2 {ms0001}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-05-29 19:16:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=129.msg1294@s{hash}msg1294
@section 3 {tx}

  @s{quotedtext}

  @p{««}I don't see the security risk of being able to intercept or
  eavesdrop on a Bitcoin transfer. @p{»»}

  @p{««}All transactions are broadcast to all Bitcoin generating nodes,
  anyway, and the transactions are impossible to alter or forge (because
  they're digitally signed). @p{»»}

  @p{««}A man-in-the-middle could drop the transaction, but SSL doesn't fix
  that@p{--} if they're relaying SSL traffic they could drop your
  SSL-encrypted transaction, too. @p{»»}

  @p{««}There are good non-security-related reasons for encrypting Bitcoin
  transaction traffic, though (makes it harder for governments/ISPs to do
  deep packet inspection to selectively drop Bitcoin traffic, for
  example). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0002}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-05-30 16:27:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=129.msg1304@s{hash}msg1304
@section 3 {tx}

  @s{quotedtext}

  @p{««}Ahh, right, I see; I hadn't thought through the mechanism of the
  pay-via-IP-address functionality. @p{»»}

  @p{««}That brings up another possible man-in-the-middle attack for HTTP
  connections: if you see a Bitcoin address on a non-secure web page, you
  can't be sure that you're seeing the correct address (a
  man-in-the-middle might have replaced it with THEIR Bitcoin address).
  And ditto for sending your Bitcoin address to somebody to request
  payment (e.g. send it via email or in your forum signature and it might
  get replaced before being displayed to people who want to send you
  money). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0003}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-05-31 16:16:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=129.msg1315@s{hash}msg1315
@section 3 {tx}

  @p{««}To get back to the original question, paying to a bitcoin addresses
  displayed on an https: webpage secured with a valid certificate is
  better. @p{»»}

  @p{««}When the bitcoin client supports secure connections to IP
  addresses, then paying to an IP address displayed on an https: webpage
  secured with a valid certificate will be just as good (security-wise,
  anyway). @p{»»}

  @p{««}Bitcoin doesn't try to solve the "am I paying who I THINK I'm
  paying problem" @p{--} we need HTTPS and signed certificates and DNSSEC
  for that (or something similar). Bitcoins are a small but really
  important piece of the payment puzzle... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0004}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-03 14:29:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=158.msg1332@s{hash}msg1332
@section 3 {tx}

  @p{««}Seems like $ would be inviting confusion, since it's followed by
  numbers that can look kind-of like a dollar amount:
  @s{btcaddr}$64.20.45.38 means send $64.20 to my bitcoin address ? @p{»»}

  @p{««}Hyphen or underscore would be less confusing, but I think period
  would work really nicely: @s{btcaddr}.64.20.45.38 @s{btcaddr}.skypaint.com
  @p{»»}

  @p{««}The advantage of that last one is it is a valid URL; if a user
  pasted that into Firefox's URL bar or searched for it in Google the
  website owner could display a helpful web page explaining how to pay.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0005}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-03 18:55:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160.msg1335@s{hash}msg1335
@section 3 {tx}

  @p{««}Has anybody tried generating bitcoins on Amazon EC2 instances? If
  you have, how many coins/day are you getting (and on what type of
  instance) ? @p{»»}

  @p{««}If nobody has already, I might do some experimenting and get some
  back-of-the-envelope estimates for $/bitcoin using Amazon EC2 spot
  instances. @p{»»}

  @p{««}(I've had zero luck generating any coins over the last week on my
  couple-year-old Macbook Pro, which only does 150-200K hashes per second)
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0006}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-03 23:47:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160.msg1339@s{hash}msg1339
@section 3 {tx}

  @p{««}One Amazon "EC2 compute unit" is, according to them, approximately
  equal to a 1ghz 2007 Xeon processor (that's a m1.small). @p{»»}

  @p{««}Judging by my laptop generating experience, there's no way an
  m1.small instance would generate enough @s{BTC} to be profitable. @p{»»}

  @p{««}The heftiest instance you can buy ("large CPU") is 20 units big,
  and costs $0.231 per hour; with bitcoins selling for about a half a
  penny each it would have to generate 46 per hour (or about a block an
  hour) to break even. Ummm.... no, that does not compute. @p{»»}

  @p{««}RE: how did I get hashes-per-second on my mac: I applied
  @p{(link}laszlo's patch@p{link)} to a version I compiled from source
  code.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0007}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-08 15:33:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=170.msg1410@s{hash}msg1410
@section 3 {tx}

  @p{««}It took me a while to figure out where to get the wx_gtk2ud-2.9
  library needed to compile bitcoind, so I thought I'd share for anybody
  else who's not a wxWidgets expert: @p{»»}

  @p{««}If you want to build bitcoind, the no-gui bitcoin daemon, you need
  the wxWidgets 'base' library. @p{brk} After untarring the wxWidgets
  source: @p{»»}

  @s{code}

  @p{««}@p{(so} I'd humbly suggest adding the above to the build-unix.txt
  file... Satoshi, is there a preferred way to submit patches? @p{so)}
  @p{brk} 27 Aug 2010: This is no longer necessary@p{--} bitcoind doesn't
  require wxwidgets at all any more.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0008}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-08 15:44:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=168.msg1411@s{hash}msg1411
@section 3 {tx}

  @p{««}It took me over a week to generate any coins, then I generated two
  blocks (100 bitcoins) in just a few hours (running bitcoin on my 2GHZ
  dual core mac laptop). @p{»»}

  @p{««}While it is fun to see bitcoins generated "out of thin air", it is
  much more important to figure out how to make them easier to buy and
  easier to spend. Since you're not a programmer/developer, I'd like to
  hear any ideas you have on how to make bitcoin less geeky and more
  user-friendly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0009}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-08 18:07:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=173.msg1420@s{hash}msg1420
@section 3 {tx}

  @p{««}In another thread venom said: @p{»»}

  @s{quotedtext}

  @p{««}So the short answer is that BC is backed by
  mathematics/cryptography and the "wisdom of crowds"; assuming there's no
  flaw in the algorithms, and assuming that there is no grand conspiracy
  of more than half of the BC nodes, it is impossible to inflate the
  currency or make fraudulent payments. @p{»»}

  @p{««}I don't believe in grand conspiracies, so that doesn't worry me.
  And I can't see any flaw in the algorithms... but that's where I'm
  skeptical (there might be bugs in the BC code, but those can and will be
  easily fixed). @p{»»}

  @p{««}Are there any professional cryptographers looking at Bitcoin?
  @p{brk} Or will they only get interested if/when Bitcoin gets popular?
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0010}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-11 01:34:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=179.msg1472@s{hash}msg1472
@section 3 {tx}

  @p{««}I'll try to answer what I can: @p{»»}

  @s{quotedtext}

  @p{««}You either have to run a node or trust somebody else (like
  MyBitcoin.com) to keep a wallet for you. @p{»»}

  @p{««}Your account balance is stored in a Berkeley DB file called
  'wallet.dat' (what directory depends on your operating system; on my Mac
  it is ~/Library/Application Support/Bitcoin/wallet.dat, on linux it is
  ~/.bitcoin/wallet.dat, not sure about PCs). @p{»»}

  @p{««}The only application that can read wallet.dat is the bitcoin code,
  and the database structure isn't documented anywhere besides the bitcoin
  C++ source code. @p{»»}

  @s{quotedtext}

  @p{««}Theoretically, no, but the code to do lightweight validation hasn't
  been written. @p{»»}

  @s{quotedtext}

  @p{««}Satoshi is planning on encrypting the wallet database, so you'd
  need to enter a password to read it. (and they need to get your private
  keys to generate transactions@p{--} those are what are stored in the
  wallet.dat) @p{»»}

  @s{quotedtext}

  @p{««}Dunno. @p{»»}

  @s{quotedtext}

  @p{««}There's another thread about this in these forums; maybe we should
  start a "Satoshi's TODO list" thread and get folks to volunteer to help
  out. @p{»»}

  @s{quotedtext}

  @p{««}Fewer and fewer coins will be created over the next N years (where
  N is@p{--} what, 20?). That's a feature, not a bug... @p{»»}

  @p{««}RE: developing your own version: are you thinking of creating a
  second bitcoin implementation that is compatible with the existing C++
  one (good idea, in my opinion)? Or creating a similar-but-not-the-same
  system (bad idea, in my opinion)?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0011}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-11 17:38:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1488@s{hash}msg1488
@section 3 {tx}

  @p{««}For my first Bitcoin coding project, I decided to do something that
  sounds really dumb: I created a web site that gives away Bitcoins. It is
  at: @s{(link)} @p{»»}

  @p{««}Five @s{BTC} per customer, first come first served, I've stocked it
  with @s{BTC}1,100 to start. I'll add more once I'm sure it is working
  properly. @p{»»}

  @p{««}Why? Because I want the Bitcoin project to succeed, and I think it
  is more likely to be a success if people can get a handful of coins to
  try it out. It can be frustrating to wait until your node generates some
  coins (and that will get more frustrating in the future), and buying
  Bitcoins is still a little bit clunky. @p{»»}

  @p{««}Please try it out and get some free coins, even if you already have
  more Bitcoins than you know what to do with. You can get some and then
  donate them right back; the address is:
  @p{(so}15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC@p{so)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0012}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-11 19:27:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1500@s{hash}msg1500
@section 3 {tx}

  @p{««}Showing the number of Bitcoins available is on my TODO list. I just
  checked and the balance is up to 1,135 (thanks to whoever donated!).
  @p{»»}

  @p{««}And right now it is 5 bitcoins per IP address (not bitcoin
  address). Not per-day@p{--} just 5. I want to start out conservatively,
  I will loosen it to 5 per (day?/week?/month?) if people start having
  lots of trouble because they get a dynamic IP address from their ISP
  that already got some. @p{»»}

  @p{««}RE: captchas: yeah, I was gonna start out with a captcha, but I
  wanted it to be as simple and non-threatening as possible. I don't
  @p{(it}think@p{it)} anybody who has access to hundreds or thousands of
  working public IP addresses would go to the effort of writing a
  bitcoin-harvesting robot, though I suppose somebody with a botnet might
  take a crack at it. To make that tougher I could make it 5 bitcoins per
  IP AND 5 bitcoins per bitcoin address (so they couldn't have all the
  bots in the botnet using the same BC address). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0013}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-12 03:32:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1512@s{hash}msg1512
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'd be happy to share the interesting bits, but the architecture
  is... um, unique. I'll start a thread on the Development forum
  describing how I built it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0014}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-12 04:09:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=186.msg1513@s{hash}msg1513
@section 3 {tx}

  @p{««}Joozero asked if I'd make the source to freebitcoins.appspot.com available, and I promised to start a thread explaining
  how I created it@p{--} and here it is. @p{»»}

  @p{««}freebitcoins is running on the Google App Engine. Well, the part
  you see is running on App Engine. @p{»»}

  @p{««}There's also a back-end bitcoind server running on a debian VPS
  that I've had for years. The App Engine code makes JSON-RPC calls via
  the App Engine url fetching API. Making that connection secure was a bit
  tricky; here's how I did it: @p{»»}

  @p{««}First, I connect to the VPS using https so the traffic is
  encrypted. @p{»»}

  @p{««}I need a secure connection because I add a secret pre-shared value
  to the JSON call. I'm not going to make the full source for freebitcoins
  fully open source because I don't want to bother with constantly working
  to keeping that secret value secret. I should hash the entire request
  with a secret key and an ever-increasing nonce, but I was lazy and I'm
  just not very worried about a man-in-the-middle attack between Google
  and my VPS. @p{»»}

  @p{««}I could have hacked my copy of the bitcoind C++ code to check for
  the secret value in requests and also modified it so it accepted
  connections from the Internet... but instead I wrote this little proxy
  server in Python that runs on the same box as bitcoind: @p{»»}

  @s{code}

  @p{««}I'm happy with how it is working. My biggest worry is that the
  bitcoind process might unexpectedly exit, or fill up the disk with
  debug.log messages, or just generally be flaky. But so far so good...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0015}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-12 11:51:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=186.msg1519@s{hash}msg1519
@section 3 {tx}

  @s{quotedtext}

  @p{««}App Engine gives me:@p{»»}

   @p{(li}Free bandwidth and data storage (with the option to pay for what
   I use if I go over a gigabyte) @p{li)}

   @p{(li}Built-in, already-configured-and-tweaked tools like memcache and
   BigTable @p{li)}

   @p{(li}An architecture where scaling up is built-in (App Engine will
   automagically replicate my app and distribute it across Google's
   worldwide content distribution network if it gets a lot of traffic)
   @p{li)}

  @p{««}And all of that is administered by Google's sysadmins (who are WAY
  better at that than I am). @p{»»}

  @p{««}But mostly I did it as an experiment and because it was a technical
  challenge and because lately I'm an App Engine fanboy. I would've been
  done a day earlier if I'd run everything on the same server and wrote
  the front end in PHP+MySQL. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0016}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-12 12:39:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=185.msg1520@s{hash}msg1520
@section 3 {tx}

  @p{««}Actually, the "label" mechanism gives me what I need to keep the
  freebitcoins separate from other bitcoins in my server's wallet. @p{»»}

  @p{««}What I'd really like is to store wallets outside of the bitcoin
  program. I'd like bitcoind to have these features: @p{»»}

    @p{(li} Generate a new address, but don't store it in the local wallet
    file@p{--} return the address and private key @p{li)}

    @p{(li} Accept a transaction that is already signed; check that it is
    new/valid, and, if it is, broadcast. (if not, reject it) @p{li)}

    @p{(li} Let me register a Bitcoin address that I'm interested in, and
    when it sees payments to that address 'tickle' a URL with details on
    that transaction. @p{li)}

  @p{««}Or, in other words, allow it to function as just a payment gateway.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0017}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-13 15:05:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1541@s{hash}msg1541
@section 3 {tx}

  @s{quotedtext}

  @p{««}How many public Tor exit nodes are there these days? You've
  essentially blacklisted 10 of them already @s{smiley} @p{»»}

  @p{««}I am going to add a one-donation-per-bitcoin address rule to make
  it a teeny-tiny bit harder to cheat. I don't want to blacklist anybody
  coming from Tor, though@p{--} I think a lot of people using Tor will
  also be interested in Bitcoin. @p{»»}

  @p{««}I'll implement a CAPTCHA when (if?) the current service starts
  running low on coins (there are 1,570 bitcoins in the faucet right
  now!). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0018}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-14 01:23:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1556@s{hash}msg1556
@section 3 {tx}

  @p{««}Thanks, lachesis@p{--} @s{BTC}50 to you for finding that bug! @p{»»}

  @p{««}I've changed the key and turned off debugging; I'll tighten up its
  security a little more tomorrow when I'm more awake. @p{»»}

  @p{««}And wobber: no, I didn't send you leet @s{BTC}

# ----------------------------------------------------------------------
@section 2 {ms0019}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-14 17:48:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1577@s{hash}msg1577
@section 3 {tx}

  @p{««}The Bitcoin Faucet now shows how many coins it has available to
  give out (on the left-hand side of the page). The number is only
  moderately accurate@p{--} donations will take 5 or 10 minutes to show up
  in the balance. @p{»»}

  @p{««}I also implemented another anti-cheating measure that should make
  casual cheating a little harder (which I don't want to say too much
  about because that would make it easy for cheaters to know what to do).
  @p{»»}

  @p{««}I'm very pleasantly surprised at how well freebitcoins is working
  so far; thanks again to everybody who tried it out and who donated
  bitcoins to it! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0020}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-17 11:38:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=195.msg1606@s{hash}msg1606
@section 3 {tx}

  @p{««}So I'm writing a little tool that dissects the Bitcoin wallet.dat,
  mainly because I want to understand better exactly how Bitcoin works.
  @p{»»}

  @p{««}And I see that the outputs of transactions have a value (number of
  bitcoins) and a bunch of bytes that are run through the little
  Forth-like scripting language built in to bitcoin. E.g.: @p{brk} @s{code}
  @p{»»}

  @p{««}First: it make me a little nervous that bitcoin has a scripting
  language in it, even though it is a really simple scripting language (no
  loops, no pointers, nothing but math and crypto). It makes me nervous
  because it is more complicated, and complication is the enemy of
  security. It also makes it harder to create a second, compatible
  implementation. But I think I can get over that. @p{»»}

  @p{««}Looking at the code, new transactions are verified by pushing the
  signature an then public key on the interpreter's stack and then running
  the TxOut script (did I get that right?). @p{»»}

  @p{««}Could I write code to create transactions with any valid script in
  the TxOut? @p{brk} E.g. could I create a TxOut with a script of:
  OP_2DROP OP_TRUE @p{brk} ... to create a coin that could be spent by
  anybody? @p{»»}

  @p{««}And is flexibility in the types of coins created the reason it is coded this way? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0021}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-17 19:58:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=195.msg1613@s{hash}msg1613
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good idea or not, SOMEBODY will try to mess up the network (or
  co-opt it for their own use) sooner or later. They'll either hack the
  existing code or write their own version, and will be a menace to the
  network. @p{»»}

  @p{««}I admire the flexibility of the scripts-in-a-transaction scheme,
  but my evil little mind immediately starts to think of ways I might
  abuse it. I could encode all sorts of interesting information in the
  TxOut script, and if non-hacked clients validated-and-then-ignored those
  transactions it would be a useful covert broadcast communication
  channel. @p{»»}

  @p{««}That's a cool feature until it gets popular and somebody decides it
  would be fun to flood the payment network with millions of transactions
  to transfer the latest Lady Gaga video to all their friends... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0022}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-19 00:30:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1621@s{hash}msg1621
@section 3 {tx}

  @p{««}Thanks! I'll add the donation address to the bottom of the page.
  @p{»»}

  @p{««}I'm thinking of keeping the donation address the same, so donations
  to the Faucet are transparent to anybody who wants to see. I WANT
  donations to, and payments from, the Bitcoin Faucet to be NON-anonymous,
  so anybody can audit that address and see the flow of bitcoins through
  the Faucet. @p{»»}

  @p{««}(by the way, if anybody is looking for an interesting
  bitcoin-related coding project I think a website where you enter a
  Bitcoin address and it shows you a visualization of all the transactions
  that went to/from that address would be cool... extra credit if it let
  you browse the web of transactions... I'd be really curious to see what
  percentage of bitcoins withdrawn from the Faucet end up donated right
  back into it...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0023}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-20 16:42:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=173.msg1629@s{hash}msg1629
@section 3 {tx}

  @s{quotedtext}

  @p{««}If it was oil, then it seems to me the country with the largest oil
  reserves would be the world's reserve currency. @p{»»}

  @p{««}It might be the biggest army, but I think the dollar is the world's
  reserve currency because the US has the largest productive economy in
  the world backing it. @p{»»}

  @p{««}Unfortunately, we might be subject to a natural experiment in the
  next couple of decades that will show us the right answer; I can imagine
  that in 20 years the US still has the world's biggest army but some
  other nation has the world's largest economy. @p{»»}

  @p{««}It would be really cool if Bitcoin Nation were the world's largest
  economy by then... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0024}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-21 13:01:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1635@s{hash}msg1635
@section 3 {tx}

  @s{quotedtext}

  @p{««}That's caused by a bug in one of the technologies I'm using behind
  the scenes (Google's App Engine). If you try again the problem should go
  away. @p{»»}

  @p{««}I've got a couple of ideas on how to make it more reliable, but I'm
  still hoping Google finds and fixes the underlying problem... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0025}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-21 15:01:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=198.msg1642@s{hash}msg1642
@section 3 {tx}

  @s{quotedtext}

  @p{««}But remember that each bitcoins can be divided into 100 million
  pieces, as needed. @p{»»}

  @p{««}And the more valuable they become, the more careful people will be
  not to lose them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0026}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-21 15:04:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg1643@s{hash}msg1643
@section 3 {tx}

  @p{««}I misunderstood the problem. I hadn't noticed that bitcoin
  addresses could be either 33 or 34 characters long, which is why the
  Faucet thought your initial address was invalid. @p{»»}

  @p{««}I've fixed it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0027}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-22 16:04:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43.msg1667@s{hash}msg1667
@section 3 {tx}

  @s{quotedtext}

  @p{««}I say keep it simple; more choices isn't always better, it just
  makes it overwhelming and confusing for most users. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0028}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-22 17:58:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=199.msg1672@s{hash}msg1672
@section 3 {tx}

  @s{quotedtext}

  @p{««}I just finished creating a clean Amazon EC2 debian 5.0 machine
  image with everything I needed to compile bitcoind, and it compiled
  (using a variation of Laszlo's makefile.unix) and is running fine (just
  finished downloading the block chain). I'll let you know if it
  misbehaves. @p{»»}

  @p{««}I had trouble compiling the gtk version, but I think that's because
  I did something wrong compiling wxWidgets. I don't need no stinkin'
  graphics (and am not a wxWidgets expert), so I'm not going to bother
  trying to fix that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0029}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-23 14:23:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=206.msg1711@s{hash}msg1711
@section 3 {tx}

  @p{««}So I've been watching the IP addresses of people getting 5 free
  bitcoins from the Bitcoin Faucet ( @s{(link)} ). @p{»»}

  @p{««}And I see some... uh, @p{(it}interesting@p{it)} patterns. Like
  these successful requests for coins: @p{»»}

  @s{code}

  @p{««}My apologies if there actually are a bunch of new bitcoin users
  using IP addresses in the 79.117 range... but I'm guessing somebody
  there is getting more than their fair share of free bitcoins. @p{»»}

  @p{««}There are several suspicious requests from the 192.38.95.* address
  block, too. @p{»»}

  @p{««}So I've made some changes to the Faucet. You won't notice them
  unless you try to cheat; if you do try to cheat, you'll have to solve a
  CAPTCHA to get coins. @p{»»}

  @p{««}If that doesn't discourage cheating, I'll modify the code so that
  if it think you're trying to cheat it requires a CAPTCHA and only gives
  out a bitcoin nickel (0.05 bitcoins)... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0030}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-23 14:47:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=204.msg1714@s{hash}msg1714
@section 3 {tx}

  @p{««}Money can be used as both a means of exchange and a store of value.
  @p{»»}

  @p{««}I plan on using Bitcoins as a convenient, very-low-cost means of
  exchange. @p{»»}

  @p{««}I don't plan on saving a significant number of Bitcoins as a store
  of value. I like to invest in people who are doing productive things
  that grow our economy and make the world a better place, so when
  Bitcoins replace dollars @s{wink} I'll lend them to people by buying
  bonds or stocks. @p{»»}

  @p{««}If you only use Bitcoins as a means of exchange, then you don't
  have to worry much about a sudden loss of faith in the system. @p{»»}

  @p{««}If you use Bitcoins as a store of value... well, then you're a
  currency speculator, which can be highly profitable but is also highly
  risky. Whether you're hoarding dollars or euros or yen or Bitcoins...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0031}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-24 18:17:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=206.msg1749@s{hash}msg1749
@section 3 {tx}

  @s{quotedtext}

  @p{««}"flawed" ?? @p{»»}

  @p{««}I've been telling people it is a half-baked,
  I've-lost-my-friggin-mind idea! @p{»»}

  @p{««}So far, I count it as a big success@p{--} I've learned a lot that
  will help me with my next Bitcoin-related project, I've made a bunch of
  people a teeny-tiny bit happier, and I've personally invested just under
  $1.00 worth of bitcoins over the last two weeks. @p{»»}

  @p{««}I did throw in the towel today and turned on reCAPTCHA for
  everybody getting bitcoins (it looks like somebody DID bother to write a
  robot to harvest coins through proxies). It was fun trying to come up
  with new, creative ways of detecting cheating, but I have more important
  things to work on. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0032}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-24 23:13:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=206.msg1757@s{hash}msg1757
@section 3 {tx}

  @s{quotedtext}

  @p{««}It is easy to generate them automatically (it is easy to write code
  that asks the Bitcoin program to generate and return a new address).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0033}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-25 19:00:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=213.msg1772@s{hash}msg1772
@section 3 {tx}

  @p{««}Copy the wallet.dat file somewhere safe and secure. @p{brk}
  To be 100% belt-and-suspenders safe, shut down Bitcoin before doing the copy. @p{»»}

  @p{««}wallet.dat is: @s{code}  (I think; I don't run Windows) @s{code} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0034}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-25 19:18:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=214.msg1773@s{hash}msg1773
@section 3 {tx}

  @p{««}I want to write an application that does stuff whenever bitcoins
  are sent to a particular Bitcoin address. @p{»»}

  @p{««}Actually, that feature would be useful for the Bitcoin Faucet (it
  could monitor the donation address and keep it's display of how many
  bitcoins are available more up-to-date; currently I memcache the balance
  and only update it every 10 minutes or so). @p{»»}

  @p{««}I want this new JSON-RPC call: @p{»»}

  @s{code}

   @p{(li}address: bitcoin address to monitor @p{li)}

   @p{(li}nConfirmations: send notification after this many transaction
   confirmations @p{li)}

   @p{(li}url: POST detail of the transaction to this url (after
   nConfirmations) @p{li)}

  @p{««}I'm thinking the POST data would look like: @p{»»}

  @s{code}

  @p{««}I don't think teaching the bitcoin client to do HTTP POSTs would be
  horribly hard; I might take a whack at implementing this myself... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0035}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-26 13:25:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=216.msg1796@s{hash}msg1796
@section 3 {tx}

  @p{««}Scheduling should be easy; on Linux, just run a couple of 'at' jobs
  that either talk to Bitcoin via bitcoind command-line arguments or use
  curl to turn on/off coin generation. @p{»»}

  @p{««}Windows and Mac have similar, built-in abilities to schedule
  commands. @p{»»}

  @p{««}I think less time, effort, and attention should be paid to coin
  generation, and more to making bitcoin as easy to use as possible for
  trading. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0036}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-26 23:15:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=206.msg1819@s{hash}msg1819
@section 3 {tx}

  @p{««}Turning on the CAPTCHA for everybody has slowed the flow of coins
  from the faucet to a very manageable trickle. @p{»»}

  @p{««}Oh, and regarding anonymity versus non-anonymity: I was careful not
  to tie IP addresses to Bitcoin addresses when implementing the Bitcoin
  Faucet. So I remember that somebody at IP address 96.240.216.119
  received bitcoins at 12:30pm today. And I remember that somebody with
  Bitcoin address @s{btcaddress}@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0037}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-26 23:54:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=218.msg1822@s{hash}msg1822
@section 3 {tx}

  @s{quotedtext}

  @p{««}You can talk to the running bitcoind either by: @p{»»}

   @p{(li}1. sending JSON-RPC calls; see @s{(link)} for more details.
   @p{li)}

   @p{(li}2. re-running bitcoind and giving it extra arguments; it will
   figure out that there's already a bitcoind running and will pass along
   the commands. @p{li)}

  @p{««}For example, running "bitcoind help" gives you the list of commands
  it understands: @p{»»}

  @s{code}

  @p{««}To figure out what your bitcoin address is, run: @s{code}
  @p{(so}(your default address has the empty string as its label).@p{so)}
  @p{»»}

  @s{code}

  @p{««} To figure out how many coins you have, run: @s{code} @p{»»}

  @p{««}Regarding running headless: the non-daemon bitcoin will run via
  remote (e.g. ssh forwarded) X-windows, if you install the necessary
  X11-client stuff on your server. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0038}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-27 01:55:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=218.msg1826@s{hash}msg1826
@section 3 {tx}

  @s{quotedtext}

  @p{««}Hmm, yeah, it's probably normal; I THOUGHT the default address was
  given an empty label; I'm wrong, they're given the label "Your Address".
  So: @s{code} should work. @p{»»}

  @p{««}Or just generate a new address, either with or without a label:
  @s{code} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0039}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-27 17:47:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=178.msg1836@s{hash}msg1836
@section 3 {tx}

  @p{««}There has been quite a lot of scholarly research on reputation
  system in the last 10 or 15 years; see @s{(link)}. @p{»»}

  @p{««}This article looks particularly relevant for Bitcoin: @p{»»}

  @p{««}Reputation Systems for Anonymous Networks @p{brk} @p{(it}Elli
  Androulaki, Seung Geol Choi, Steven M. Bellovin, and Tal Malkin
  Department of Computer Science, Columbia University@p{it)}
  (elli,sgchoi,smb,tal)@s{at}cs.columbia.edu @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms0040}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-29 15:27:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69.msg1874@s{hash}msg1874
@section 3 {tx}

  @p{««}I did some research into money exchanging and money transfer
  regulations in the U.S. @p{»»}

  @p{««}The raw legal code is online at: @s{(link)} @p{»»}

  @p{««}I am not a lawyer; trying to understand legalese is just an odd
  hobby of mine. From my reading of the regulations, if you exchange less
  than $1,000.USD worth of Bitcoin per day you don't have to worry: @p{»»}

  @s{quotedtext}

  @p{««}It looks to me like if you exchanged more than $1,000.USD per day a
  good lawyer might be able to argue that Bitcoins do not meet the legal
  definition of "currency": @p{»»}

  @s{quotedtext}

  @p{««}Then again, if Bitcoins are not legally "currency" then it might be
  left up to a Court to decide what, exactly, they are, and the result
  might be really unpleasant (if a judge decided that they're like stocks
  and are therefore subject to regulation by the Security and Exchange
  Commision you might find yourself in jail for being an unlicensed stock
  broker). @p{»»}

  @p{««}I think Bitcoin needs some licensed, regulated exchanges that abide
  by all the regulations, treating Bitcoins just like another foreign
  currency, and make it really easy to buy or sell a few hundred dollars
  worth of Bitcoins. The regulations are not as onerous as I expected;
  basically you just have to get identification from customers that make
  large transactions and report them.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0041}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-29 16:58:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221.msg1876@s{hash}msg1876
@section 3 {tx}

  @p{««}I think bittorrent would be a really good model to follow. @p{»»}

  @p{««}But it's not the only path to success; Perl is a good example of a
  successful technology with One True implementation and no specification
  beyond the One True implementation. @p{»»}

  @p{««}Then again, development of Perl 6 seems to be going really slowly.
  @p{»»}

  @p{««}And I think breaking up the functionality is a really good idea.
  For example, if the algorithm for signing transactions and the format
  for public and private keys were standardized it would be possible to
  create a Bitcoin iPhone app that stored the private keys (wallet) on the
  phone and submitted signed transactions to a proxy that was connected to
  the p2p network. @p{»»}

  @p{««}I see the functionality broken out into these pieces: @p{»»}

  @p{(li}1. p2p nodes that are constantly connected and relay blocks and
  transactions @p{li)}

  @p{(li}2. transaction monitoring ("tell me when there are new
  transactions that match some set of criteria") @p{li)}

  @p{(li}3. new block monitoring ("tell me when there are new blocks that
  match some set of criteria") @p{li)}

  @p{(li}4. transaction validation (answers question "is this transaction
  valid, and how many validations does it have?") @p{li)}

  @p{(li}5. block validation ("is this block valid, and how many
  validations does it have?") @p{li)}

  @p{(li}6. bitcoin mining: race to generate a new block and earn @s{BTC}
  @p{li)}

  @p{(li}7. wallet storage (generate new addresses, and store their
  public/private keys and any transactions that correspond to them)
  @p{li)}

  @p{(li}8. generate new transactions (sign @s{BTC} with private key(s)
  and submit to p2p network) @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0042}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-06-30 21:21:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=227.msg1898@s{hash}msg1898
@section 3 {tx}

  @p{««}I am not a lawyer. @p{»»}

  @p{««}But it looks to me like No, just running Bitcoin doesn't make you a
  "money transmitting business." To be a "business" you have to be
  charging people for your service. @p{»»}

  @p{««}If you're running Bitcoin to buy or sell goods or services in
  exchange for bitcoins, I'd say you're not in the money transmitting
  business. @p{»»}

  @p{««}However, if I were to start a company in the business of buying and
  selling Bitcoins, or that was a Bitcoin payment processing intermediary
  that took a percentage of transactions between buyers and sellers, I'd
  talk to a lawyer and jump through all the legal hoops (looks like here
  in Massachusetts I'd need a license and would have to post a $50,000
  bond). @p{»»}

  @p{««}Or to put it in more concrete terms: I am not a money transmitting
  business when I use my credit card to pay for something from Amazon.com.
  @p{brk} And Amazon.com is not a money transmitting business just because
  they accept payments. @p{»»}

  @p{««}However, Amazon Payments, Inc. (Amazon's Paypal competitor)
  @p{(bf}is@p{bf)} licensed as a money service business in a bunch of US
  states. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0043}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-01 00:14:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=227.msg1901@s{hash}msg1901
@section 3 {tx}

  @s{quotedtext}

  @p{««}I am not a lawyer. @p{»»}

  @p{««}But if you generated bitcoins and then sold them I'd think you'd
  only done something illegal when you fail to declare that income on your
  income tax return. Just like if you grew tomatoes in your back yard and
  sold them to somebody. You aren't likely to get into any trouble until
  you make a lot of money on tomatoes and then fail to report that income
  to the IRS (or you get shut down for farming in a residential zone or
  something). @p{»»}

  @p{««}I think that applies to what madhatter is doing (taking payment for
  bitcoins through the mail). But again, I am not a lawyer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0044}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-02 00:06:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=228.msg1921@s{hash}msg1921
@section 3 {tx}

  @s{quotedtext}

  @p{««}... or, in other words: have you thought about what will happen
  when somebody buys a bunch of bitcoins from you and then disputes the
  charge on their credit card? @p{»»}

  @p{««}Or worse: buys a bunch from you, turns around and sells them to
  you. Waits a day. Does it again. @p{brk} And then disputes all the
  charges at the end of the month... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0045}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-02 00:21:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=202.msg1922@s{hash}msg1922
@section 3 {tx}

  @p{««}If you're worried about elliptic curve cryptography being broken,
  then don't store any significant wealth in Bitcoin. Just like if you're
  worried about your (real, physical) wallet being stolen don't hold more
  cash than you need to get through a couple of days of purchases. @p{»»}

  @p{««}By the way: I think an economical method for separating gold atoms
  from seawater will be found before elliptic curve cryptography is broken
  (and I think both are unlikely in the next 25 years). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0046}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-04 12:50:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=231.msg1941@s{hash}msg1941
@section 3 {tx}

  @p{««}I've started reverse-engineering and documenting the wallet and
  block databases, and have written some Python code that deserializes
  many of the Bitcoin data structures. I was going to let it ferment a
  little more before announcing, but Mr. Google will surely find and index
  it soon, and it should be a good head start for anybody who wants to
  start a Python bitcoin client. @p{»»}

  @p{««}Open source, MIT license, at: @p{brk} @p{(so}@s{(link)}@p{so)}
  MOVED TO git: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0047}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-05 20:29:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=235.msg1975@s{hash}msg1975
@section 3 {tx}

  @p{««}An example of how bitcoin works on a bit-level: Ok, I'll give it a
  shot. @p{»»}

  @p{««}Here's what the current best-block (according to my bitcoin client)
  looks like, dumped in a geek-readable format: @p{»»}

  @s{code}

  @p{««}So: that big long string of hex at the top is the block header's
  hash value. Note that it ends with 8 zeroes; that's the proof-of-work
  (my utility for dumping blocks doesn't bother dumping the Nonce values).
  @p{»»}

  @p{««}What's hashed in the block header? The Nonce. The block's
  generation time. The previous block's hash. And a hash of all the
  transactions in the block. (and probably some stuff I'm forgetting).
  @p{»»}

  @p{««}This block has three transactions in it. The first is the 50.00
  (which is really 5,000,000,000 of the smallest possible units) reward
  for finding/creating the block. It can only be spent by whoever has the
  private key that matches the public key in the TxOut
  (17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 @p{--} you can think of public keys
  and bitcoin addresses as equivalent), which will be whoever generated
  the block. @p{»»}

  @p{««}The second is a payment of 50.0 from.... somebody... to...
  somebody. How does Bitcoin know that transaction is valid? Well, it:.
  @p{»»}

    @p{(li} Looks up the previous transaction. That's the TxIn:
    prev(580a...e82e:0) stuff@p{--} fetch TxOut zero (which will be a coin
    generated txn) from previous transaction 580a.... @p{li)}

    @p{(li} EVALUATE(TxIn.pubkey + previous transaction TxOut.pubkey) and
    make sure it evaluates to true. This is where the cryptography
    happens; the receiver uses the private key known only to them and
    provides a correct digital signature. @p{li)}

  @p{««}The third is a payment of 150.0 (three 50.0-value in, one
  150.0-value out). @p{»»}

  @p{««}Clear as mud? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0048}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-07 13:52:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=235.msg2018@s{hash}msg2018
@section 3 {tx}

  @p{««}The "scripting language" ("expression evaluator" would be more
  accurate) is a little stack-based intepreter that looks at lot like
  Forth. @p{»»}

  @p{««}So, for example, here's an example of a GENERATED coin getting
  spent: @p{»»}

  @p{««}@s{code}@p{»»}

  @p{««}That's intepreted as: @p{»»}

    @p{(li}PUSH a 73 byte value onto the stack @p{li)}

    @p{(li}PUSH a 65 byte value onto the stack @p{li)}

    @p{(li}call CHECKSIG. CHECKSIG pops two values off the stack (public
    key and digital signature), then does the @p{(link}digital signature
    thing@p{link)} using the @p{(link}OpenSSL ECDSA_Verify()@p{link)}
    function. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0049}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-07 17:57:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=241.msg2026@s{hash}msg2026
@section 3 {tx}

  @p{««}Whatever mechanism is chosen, it had better not significantly slow
  down the network or client unless strong anonymity is
  required/requested. @p{»»}

  @p{««}I've tried I2P and Tor, and, for me, super-strong privacy isn't
  worth the performance cost. @p{»»}

  @p{««}Also, regarding forking the block chain by a network split: @p{»»}

  @p{««}It's only "really bad" if I can get away with double-spending some
  coins before the network merges again. @p{brk} If I'm buying valuable
  stuff, then the merchants will likely require 6 confirmations before
  releasing the goods, so I'd have to be able to keep the network split
  for an hour or more. @p{»»}

  @p{««}Merchants will likely have very-well-connected, long-running nodes.
  For example, the Bitcoin Faucet has 66 connections right now. If I
  wanted to try to implement a "fork the block chain attack" I'd have to
  somehow manage to insert my "cancer nodes" in between two merchants that
  I want to rip off (I'll end up ripping off one of the two, because
  eventually one of the two double-spend transactions will "win"). @p{»»}

  @p{««}I don't know enough about network analysis to figure out how many
  cancer nodes you'd need to have a significant chance of getting in
  between two merchants with 60+ connections in a network of (say) 1,000
  non-cancerous nodes, but I bet it is a very large number. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0050}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-07 18:41:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=241.msg2030@s{hash}msg2030
@section 3 {tx}

  @p{««}Would the transactions on the other block chain be lost? @p{»»}

  @p{««}I thought they'd just be re-integrated into the new-best-chain (if
  they were valid), just starting with '1 confirmation' again... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0051}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-08 00:11:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=241.msg2045@s{hash}msg2045
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm sure somebody somewhere would/will be happy to sell you
  bitcoins anonymously; just put cash and a bitcoin receiving address in
  an envelope and mail it. The exchange (who you'd have to trust to
  actually send you the coins) takes the cash and send coins to the
  address. They have no idea who you are, and your identity isn't linked
  to the coins. @p{»»}

  @p{««}Well, it isn't linked to the coins until you forget to turn on TOR
  or I2P before spending coins on something illegal. Or you remain
  completely and utterly anonymous right up until you spend coins on
  something physical and have it shipped to your home address. Or you
  arrange to have contraband "dead dropped" somewhere, and you get
  arrested when you go to pick it up. @p{»»}

  @p{««}None of which have anything to do with Bitcoins, and all of which
  seem to me to be more likely ways of getting into trouble than somebody
  managing to figure out that "transaction for purchase of illegal stuff"
  is linked to "Gavin purchased a bunch of Bitcoins from Bobby's Discount
  Bitcoin Emporium" last year. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0052}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-09 11:59:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=249.msg2083@s{hash}msg2083
@section 3 {tx}

  @p{««}In a thread in the Bitcoin Discussion forum, dwdollar says: @p{»»}

  @s{quotedtext}

  @p{««}I think it will be impossible to tell if a bubble&amp;crash is
  "natural" or "the men in black helicopters manipulating the system."
  @p{»»}

  @p{««}Bitcoin will get mentioned someplace with lots of readers, a bunch
  of those readers will like the idea and try to buy Bitcoins, their price
  will rise which will draw even more people to "invest", which will drive
  the price up even more... until people decide that the price isn't going
  to rise any more and everybody rushes to sell before the price drops. I
  predict there will be between one and five Bitcoin bubbles (price will
  double or more and then crash back down below the starting price) in the
  next four years . @p{»»}

  @p{««}What do you all think@p{--} are bubbles and crashes a natural
  emergent property of markets, or would Bitcoin be immune if nobody were
  @p{(bf}trying@p{bf)} to cause a bubble? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0053}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-09 18:11:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=240.msg2104@s{hash}msg2104
@section 3 {tx}

  @p{««}It's a bad idea to try to break the "in-production" bitcoin
  network. @p{»»}

  @p{««}If anybody is starting serious work on either extending Bitcoin or
  developing compatible implementations or trying to break it by creating
  bad transactions, I think creating a "parallel universe" test network
  with its own block chain, data directory, etc makes sense. @p{»»}

  @p{««}Satoshi: would you be open to a @p{--}testnetwork (or something)
  flag to bitcoin that swapped to an alternate genesis block, data
  directory, listen port and IRC channel? Maybe with a really short
  average block generation time, too (like once per minute instead of once
  per 10 minutes) so everything happens ten times a fast to make testing
  quicker. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0054}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 12:08:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg2295@s{hash}msg2295
@section 3 {tx}

  @p{««}From the source code: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0055}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 13:05:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=286.msg2303@s{hash}msg2303
@section 3 {tx}

  @p{««}By the time Bitcoins replace the Euro @s{tongue} I think most
  people will be running lightweight clients on wireless smartcards in
  their (physical) wallet that don't pay attention to every single
  transaction. @p{»»}

  @p{««}But that's WAAAY down the road. And who knows, by then maybe we'll
  all have a hundred-gigabits of bandwidth in our pants. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0056}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 13:36:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg2311@s{hash}msg2311
@section 3 {tx}

  @s{quotedtext}

  @p{««}If you have finished downloading the "block chain" (the history of
  previous transactions) then you'll get your bitcoins right away. @p{»»}

  @p{««}If you haven't finished that initial download (if the "blocks"
  number at the bottom of Bitcoin is less than 65-thousand-something),
  then you'll get your free bitcoins as soon as you download the block
  containing that 5-bitcoin transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0057}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 14:45:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg2319@s{hash}msg2319
@section 3 {tx}

  @p{««}But how would you distinguish between a legitimate
  micropayment-processing IP and a spammy "I want to make Bitcoin use so
  much bandwidth nobody is willing to run it any more" IP? @p{»»}

  @p{««}Really small micropayments seem to me to be a really hard problem,
  and I don't think Bitcoin should try to solve too many very hard
  problems all at once. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0058}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 15:22:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg2328@s{hash}msg2328
@section 3 {tx}

  @s{quotedtext}

  @p{««} The fee is paid to whoever generates the block that the
  transactions are in, and that's random. @p{»»}

  @p{««}Your friend could run a node that refunds the fee, but unless your
  friend can convince a lot of other people to run nodes that do the same
  thing you're almost certainly going to end up paying the fee. @p{»»}

  @p{««}Remember that all transactions (even payments from you to your
  friend) are broadcast across the payment network; they HAVE to be,
  because if they weren't you could spend the same coins twice without
  getting caught. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0059}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 16:39:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=292.msg2338@s{hash}msg2338
@section 3 {tx}

  @p{««}Reminder to anybody running a bitcoind server: be sure the
  debug.log isn't filling up your server's disk. With the slashdotting,
  now might be a good time to setup a debug.log housekeeping system. @p{»»}

  @p{««}I'm doing this on my Debian server: @p{»»}

  @p{««}My crontab: @p{»»}

  @s{code}

  @p{««}My bc_logrotate.conf file: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0060}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 19:15:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=295.msg2365@s{hash}msg2365
@section 3 {tx}

  @p{««}The Bitcoin Faucet is handling the slashdotting really well...
  except that I'm running out of coins to give away. over 5,000 have
  flowed out of the Faucet since I refilled it last night. @p{»»}

  @p{««}Any of you early adopters who generated tens of thousands of coins
  back in the early days, are you willing to send a few to the Faucet to
  be given away so more people can try out Bitcoin? I know that most of
  them are likely to be lost (I suspect there a lot of slashdot
  lookey-loos who won't stick around long enough to spend their 5
  bitcoins), but if that's the case then that'll just increase the value
  of your other bitcoins, anyway... @p{»»}

  @p{««}Fountain donation address is: @p{(so}@s{btcaddress}@p{so)} @p{»»}

  @p{««}Depending on donations and how long the slashdotting lasts, I might
  have to start giving away bitnickels...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0061}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 21:30:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=301.msg2387@s{hash}msg2387
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure, you could build specialized hardware that computed SHA256
  hashes faster than ANYBODY! @p{brk} And then you'd be able to generate
  most of the bitcoins. @p{»»}

  @p{««}So: how much would it cost you, in dollars or euros@p{--} and don't
  forget to pay yourself for the time needed to design and build such a
  system? @p{»»}

  @p{««}Because you'd be able to generate, at most, 50 bitcoins every 10
  minutes or so. Soon after you started generating, all the other nodes on
  the network notice that bitcoins are being generated quicker than normal
  and increase the difficulty of the problem being solved (you've gotta
  twiddle the block header more times to find SHA256Hash(block_header)
  @p{lt} target_value ). @p{»»}

  @p{««}If Bitcoins become even more wildly popular, then maybe people will
  think they can profit by building or renting specialized hardware. That
  would be a very good problem for Bitcoin to have. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0062}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 23:24:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=290.msg2421@s{hash}msg2421
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's when I sleep! Meeting whenever is most convenient for
  Satoshi makes sense to me.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0063}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-12 23:32:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=249.msg2424@s{hash}msg2424
@section 3 {tx}

  @p{««}First: it looks like we're in the middle of our first Bitcoin
  Bubble. Price today went from about 0.8 US cents to 1.4 US cents on the
  Bitcoin Market. Maybe the price won't crash back down... will be
  interesting to see what happens. @p{»»}

  @p{««}Second, RE: lending: I think it's going to be really hard to
  establish enough trust to create a lending bitcoin bank. I base that on
  my experiences dabbling as a Prosper.com lender; when hard times hit,
  repaying your Bitcoin debts will be WAAAAY down on the priority list.
  @p{»»}

  @p{««}Instead, I think we'll see Ponzi schemes masquerading as lending
  banks. Buyer beware! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0064}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-13 00:52:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=304.msg2441@s{hash}msg2441
@section 3 {tx}

  @p{««}Transactions with "0 confirmations" are transactions that your
  client has seen, but haven't been put into a block yet. @p{»»}

  @p{««}Here's what happened when you bought the bitcoins: @p{»»}

  @p{««}Seller: "Hey Bitcoin Network! These here Bitcoins are getting sent
  to that there Bitcoin Address!" @p{»»}

  @p{««}Your client, listening in on all the payment network messages:
  "Wow, spiffy, that's one of MY Bicoin Addresses! I'll add that
  transaction to my wallet, and show that transaction as 0/unconfirmed in
  the UI." @p{»»}

  @p{««}Then your client goes on its merry way downloading the 66,241
  blocks in the block chain. @p{»»}

  @p{««}In the meantime, some lucky soul generates block number 66,242, and
  includes your transaction in that block. When your client connects that
  block up to the block chain (which it won't do until it gets all 64,241
  previous blocks), it'll show it as "1/unconfirmed" @p{»»}

  @p{««}Then 2 confirmations when block 66,243 gets generated, etc. @p{»»}

  @p{««}Wonky things can happen if two nodes generate a different block
  66,241 (especially if one of them included your transaction and one of
  them didn't, you can go from 1/unconfirmed back to 0/unconfirmed for a
  little while), but after a couple more blocks get generated everything
  sorts itself out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0065}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-13 01:04:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg2446@s{hash}msg2446
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yeah, I could, but it seemed like more trouble than it was worth;
  if you got coins from the Faucet into a non-empty wallet and then
  donated them back there's no guarantee that the donation back would be
  the SAME coins. I just don't want to deal with a lot of "I got five
  coins and then sent back ten but I still can't get more from the
  Faucet...." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0066}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-13 01:57:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=295.msg2453@s{hash}msg2453
@section 3 {tx}

  @p{««}Thanks for the donations... whoever you are who donated! @p{»»}

  @p{««}The Faucet has about 2,000 coins in it at the moment; I just
  deployed a new version that will automatically start giving out
  bit-nickels if the balance falls below 500 (but allows anybody who gets
  a bit-nickel to come back later and get the 5 bitcoins "they deserve"
  if/when the Faucet is refilled). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0067}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-13 02:56:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=310.msg2465@s{hash}msg2465
@section 3 {tx}

  @p{««}After he's downloaded all 66,312 blocks and is up-to-date,
  transactions are very fast.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0068}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-13 15:53:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=245.msg2570@s{hash}msg2570
@section 3 {tx}

  @p{««}... like how the RIAA screws around trying to disrupt BitTorrent
  swarms... @p{»»}

  @p{««}Umm, good luck with that. I'm betting The Swarm will win most of
  the battles. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0069}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 00:42:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=286.msg2696@s{hash}msg2696
@section 3 {tx}

  @s{quotedtext}

  @p{««}That sounds about right. @p{»»}

  @p{««}So a million transactions a day would be 600 million bytes. 600
  megabytes a day, 18 GB a month. @p{»»}

  @p{««}That's not bad. Actual network bandwidth will be higher (the way
  the network is connected you get the same transaction multiple times
  from your peers). You won't be running an always-connected-network node
  on your iPhone, but any low-cost server will give you twenty times that
  bandwidth per month. And 18GB isn't much disk space in these days of
  terabyte hard drives. @p{»»}

  @p{««}A million transactions per day is a @p{(bf}LOT@p{bf)}! For
  comparison, in 2006 there were about @p{(link}60 million credit card
  transactions per day in the US@p{link)}. @p{»»}

  @p{««}Eventually, if Bitcoin survives and gets as popular as credit cards
  for paying for stuff I expect somebody will create a compatible version
  with a more efficient network structure (maybe by that time there will
  be some fancy IPV6 multicast protocol or something). And they'll
  implement a couple of gateway nodes (running on really fast connections)
  that shuttle transaction and block traffic from the current Bitcoin
  network into the super-efficient network. And I expect most of us will
  be running lightweight clients that just keep our wallets, sign
  transactions, and send and receive transactions to the ultra-fast nodes
  that ARE looking at every transaction. @p{»»}

  @p{««}You know, kind of like how we have those Big Routers in the Sky
  that handle Internet backbone traffic (or the ultra-fast DNS root
  servers). The Internet didn't start out with astoundingly fast routers
  zinging packets around. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0070}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 01:44:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=300.msg2710@s{hash}msg2710
@section 3 {tx}

  @p{««}No, actually, in the current source code it never gets lowered:
  @p{»»}

  @s{code}

  @p{««}There's no "@s{code}" @p{»»}

  @p{««}@p{(bf}UPDATE@p{bf)}: rodin is right, I'm wrong. bnProofOfWorkLimit
  is a constant, and this code just make sure the proof of work never gets
  too easy.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0071}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 02:20:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=286.msg2721@s{hash}msg2721
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm imagining: @p{»»}

  @p{««}A lightweight client would have a wallet with coins in it
  (public+private key pairs). @p{»»}

  @p{««}And a secure way of sending messages to, and getting messages from,
  any of the ultra-fast, always-connected heavyweight nodes. @p{»»}

  @p{««}The lightweight client sends money by: @p{»»}

    @p{(li}creating a transaction (signing coins with the private key)
    @p{li)}

    @p{(li}sending the signed transaction securely to the ultra-fast
    server, which puts it on the network. @p{li)}

    @p{(li}receiving confirmation that the transaction was valid and sent,
    and updating its wallet (marks coins as spent) @p{li)}

    @p{(li} (or getting a "you already spent those coins" error from the
    server) @p{li)}

  @p{««}The lightweight client receives money by: @p{»»}

    @p{(li}Either polling the server every once in a while, asking "Any
    payments to these BC addresses that I have in my wallet?" @p{li)}

     @p{(li}... or asking the server to tell it whenever it sees a
     transaction to a list of BC addresses (or maybe when it sees a
     relevant transaction with N confirmations) @p{li)}

  @p{««}When transactions occur, the lightweight client updates its wallet
  (adds the coins). @p{»»}

  @p{««}You don't have to trust the server; it never has your private keys.
  @p{»»}

  @p{««}Well, you do have to trust that the server doesn't lie about
  whether your transactions are valid or not, but why would the server lie
  about that? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0072}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 02:52:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=245.msg2731@s{hash}msg2731
@section 3 {tx}

  @p{««}Yeah, that would be a good problem to have. @p{»»}

  @p{««}Why would they mess around with the block chain, though? Are you
  imagining the men in black double-spending enough Bitcoins to make
  merchants think it is untrustworthy? ("I shipped 100 computers to
  Langley, Virginia when the transaction had six confirmations, and now
  there's a new block chain that says those coins were paid to somebody
  else!!!") @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0073}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 04:22:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=286.msg2745@s{hash}msg2745
@section 3 {tx}

  @p{««}Making it easier for merchants to accept bitcoins, and users to pay
  using them, aught to be priority number 1. @p{»»}

  @p{««}There's a great talk by the CTO of Facebook available on Youtube,
  and I think he gave the right advice on scaling: "Don't worry much about
  it until just before it becomes a problem. Don't overengineer, because
  you're likely to waste time doing something that turns out to be
  irrelevant." @p{»»}

  @p{««}I think Satoshi has done an amazingly fantastic job; over the last
  two days of Bitcoin being "slashdotted" I haven't heard of ANY problems
  with Bitcoin transactions getting lost, or of the network crashing due
  to the load, or any problem at all with the core functionality. @p{»»}

  @p{««}Yes, it's annoying to have to wait for the block chain to download
  (especially with the Microsoft Security Essentials weirdness), and yes
  it would be nice if all the pieces of Bitcoin functionality were already
  nicely separated and ready to be rearranged and extended in all the ways
  we all want to rearrange and extend it. But I've been poking at the
  Bitcoin code for over a month now, and the more I learn the more
  impressed I become at the thought that's gone into it. @p{»»}

  @p{««}This quote seems appropriate: @s{quotedtext} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0074}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 11:43:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=245.msg2806@s{hash}msg2806
@section 3 {tx}

  @p{««}My point was that if "they" mount an attack, I think they're
  unlikely to do something subtle like try to mess with the block chain.
  @p{»»}

  @p{««}If "they" want to mess with the network, it would be far easier to
  do something like what China's doing with its Great Wall@p{--} forcing
  connections they don't like to be dropped. Or what botnets do now: mount
  a denial-of-service attack by flooding the network. @p{»»}

  @p{««}Much more likely: "they" will catch you for tax evasion when you
  convert your bitcoins to your local fiat currency and buy that fancy
  sports car you've always wanted. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0075}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 12:59:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=336.msg2816@s{hash}msg2816
@section 3 {tx}

  @p{««}5 lots (25 BTC) on 011 please. @p{»»}

  @p{««}Eleven is my favorite number. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0076}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 13:04:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=295.msg2817@s{hash}msg2817
@section 3 {tx}

  @p{««}Thanks Xavier! @p{»»}

  @p{««}To everyone else: the Faucet is now giving out bit-nickels; it just
  went under 500 BTC. I've got just under 2,000 BTC left to refill it, but
  I think I'll start letting it drain a nickel-at-a-time and keep it above
  zero for as long as I can (refilling it to just under 500 if it gets
  near zero). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0077}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 14:14:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=347.msg2831@s{hash}msg2831
@section 3 {tx}

  @p{««}So about two hours ago (8AM EST, 24 July) I see a big spike in
  traffic to the Bitcoin Faucet: @p{brk} @s{image} @p{»»}

  @p{««}What's up with that? The slashdot effect was just tapering off...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0078}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-14 15:18:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=336.msg2842@s{hash}msg2842
@section 3 {tx}

  @p{««}Ok. @p{»»}

  @p{««}As long as I get eleven. @p{»»}

  @p{««}(it's my favorite number) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0079}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 00:51:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3018@s{hash}msg3018
@section 3 {tx}

  @p{««}I went ahead and created a modified Bitcoin client with a brand-new
  block chain and a few other changes (detailed below) that will make it
  independent of the "production" Bitcoin network. @p{»»}

  @p{««}I intend to use it to test out some code I'm writing for my next
  project; I don't want to accidentally break (or slowdown or otherwise
  interfere with) the real Bitcoin network. It should also be useful for
  anybody who wants to see if they can purposely break Bitcoin (for the
  purposes of a security audit). @p{»»}

  @p{««}Code is hosted at github: @s{(link)} @p{»»}

  @p{««}Patches to go from 'production' bitcoin to 'TEST network' bitcoin
  are also at github: @s{(link)} @p{»»}

  @p{««}... so go nuts and start hacking. @p{»»}

  @p{««}Changes are: @p{»»}

  @p{««}+ Listen port is 18333 (instead of 8333). Uses 18332 for JSON-RPC
  (instead of 8332). @p{»»}

    @p{(li}@p{(li} Uses irc.lfnet.org channel @s{hash}bitcoinTEST for
    bootstrapping. @p{li)}

    @p{(li} Never tries to connect to "well known" nodes for
    bootstrapping. @p{li)}

    @p{(li} Uses bitcoinTEST for the default data directory (e.g.
    ~/.bitcoinTEST on Linux, %APPDATA%/BitcoinTEST on Windows, etc)
    @p{li)}

    @p{(li} Uses a different ADDRESSVERSION for Bitcoin Addresses (0xff
    instead of 0x0), so you can't screw up copying and pasting Bitcoin
    addresses (if you try to use a TEST address on the production system
    it will tell you it's invalid; you can, however, lose TESTcoins by
    trying to send them to a valid production address) @p{li)}

    @p{(li}+ Has a brand-new block chain (with a different genesis block)
    @p{li)}

    @p{(li}+ Initial difficulty is 4 times easier than production Bitcoin
    @p{li)}

    @p{(li}+ protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda }
    instead of { 0xf9, 0xbe, 0xb4, 0xd9 } @p{li)}

  @p{««}@p{(it}(16 July: "++" stuff added in response to the suggestions
  below in this thread)@p{it)} @p{»»}

  @p{««}A very generous TEST Bitcoin Faucet is running at: @s{(link)} @p{»»}

  @p{««}I think the TEST and production GUIs don't play well with each
  other; at least on my Mac, I have to quit the "real" bitcoin before
  running TEST. That's probably an easy fix, I just need to figure out
  how... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0080}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 01:05:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=360.msg3024@s{hash}msg3024
@section 3 {tx}

  @s{quotedtext}

  @p{««} If I understand correctly, you've got two chances to find a
  collision instead of one. @p{»»}

  @p{««}So this decreases the security of SHA256 by a factor of 2... which
  is just Not a Big Deal. Bitcoin is using, essentially SHA255 instead of
  SHA256. It'll still take longer than forever to find a collision...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0081}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 01:28:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=173.msg3038@s{hash}msg3038
@section 3 {tx}

  @p{««}Yep, Americans have been getting a really sweet deal from the
  Chinese for a while now@p{--} we send them pieces of paper with dead
  presidents on them (well, the electronic equivalent) and they send us
  all sorts of useful stuff. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0082}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 01:40:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3043@s{hash}msg3043
@section 3 {tx}

  @p{««}Very good point about the genesis block. @p{»»}

  @p{««}Unfortunately, I'm not exactly sure HOW to generate a valid genesis
  block; I can tweak the data but need to generate a valid block hash...
  hmm, I see some time in gdb in my near future... @p{»»}

  @p{««}RE: changing the protocol version: Good Idea, too. Every wire
  protocol message starts with the bytes '{ 0xf9, 0xbe, 0xb4, 0xd9 }',
  I'll tweak that in the TEST code so TEST and production clients can't
  talk to each other even if they manage to get connected. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0083}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 02:28:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=360.msg3060@s{hash}msg3060
@section 3 {tx}

  @p{««}There's a @p{(link}stackoverflow@p{link)} question about double
  hashing, by the way. Consensus is that it's not less secure. It's too
  late for my brain to process the nuances of hashing... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0084}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 03:51:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3084@s{hash}msg3084
@section 3 {tx}

  @p{««}It's @p{(bf}ALIVE@p{bf)}! @p{»»}

  @p{««}@s{image} @p{»»}

  @p{««}Source on git now has: @p{»»}

  @p{««}+ different genesis block @p{»»}

    @p{(li}@p{(li} ridiculously easy minimum proof of work threshold
    @p{li)}

    @p{(li} protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda }
    instead of { 0xf9, 0xbe, 0xb4, 0xd9 } @p{li)}

  @p{««}If you compile and connect and turn on coin generation you'll
  generate a lot of play money quickly... @p{brk} (I've turned off
  generation, but will keep my three clients @p{--} two Linux, one Mac
  @p{--} connected)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0085}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 14:33:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=376.msg3158@s{hash}msg3158
@section 3 {tx}

  @p{««}That's right. @p{»»}

  @p{««}One of Bitcoin's big advantages is that you can be your own bank;
  you don't have to trust a government-backed fractional reserve bank to
  keep your extra cash safe. @p{»»}

  @p{««}If you WANT to trust a fractional-reserve Bitcoin Bank, feel free.
  But don't go crying to your congressman if you lose all your money,
  please.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0086}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 16:14:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=376.msg3181@s{hash}msg3181
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's like saying: "Gold atoms are unstable because quantum
  mechanics tells us that there is a @s{gt}0 possibility that they will
  spontaneously decay." @p{»»}

  @p{««}Yes, in the very very very long run the universe will suffer heat
  death and there will be no gold (or any other atoms) left. @p{»»}

  @p{««}If the probability of bank runs is very small, then fractional
  reserve banking works. Or, in other words, if banks can establish and
  maintain trust in their ability to repay deposits they'll be stable even
  if they practice fractional reserve banking. @p{»»}

  @p{««}I hope we'll eventually find out the hard way if, or which, Bitcoin
  banks can establish and maintain trust. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0087}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-15 23:49:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=395.msg3326@s{hash}msg3326
@section 3 {tx}

  @s{quotedtext}

  @p{««} Every generated coin gets a unique address, so you until they get
  bundled together and sent somewhere you don't know to whom ("whom" as in
  "which Bitcoin Address") they belong. @p{»»}

  @s{quotedtext}

  @p{««} You can get the top 10 addresses that have received the most coins
  (and could figure out how many have gone back out), but there will
  probably be a lot of generated coins that have never been spent which
  will just look like little 50-coin islands. @p{»»}

  @s{quotedtext}

  @p{««} Yes; the @p{(so}BitFountain@p{so)} @p{(so}BitTap@p{so)} BitFaucet
  donation address doesn't change, so you can see how many bitcoins have
  gone in. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0088}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-16 01:29:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3347@s{hash}msg3347
@section 3 {tx}

  @p{««}I know EricJ2190 tried out the test network today@p{--} Eric (and
  anybody else who might have compiled and run) you need to git pull,
  recompile, and nuke your ~/.bitcoinTEST directory. The client was
  generating blocks WAY too fast. @p{»»}

  @p{««}That'll teach me to go messing with code I don't really understand
  (on the bright side, I now know what the OpenSSL BN_bn2mpi() routine
  does). @p{»»}

  @p{««}Oh, and Eric: I added your pnSeed fix to my git branch. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0089}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-16 03:42:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3375@s{hash}msg3375
@section 3 {tx}

  @s{quotedtext}

  @p{««}The TEST Faucet will be running on host:
  li133-197.members.linode.com @p{brk} (starting tomorrow, if all goes as
  planned). You can connect to it to bootstrap. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0090}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-16 13:41:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412.msg3467@s{hash}msg3467
@section 3 {tx}

  @p{««}Unix and Mac and Windows all have ways of scheduling recurring
  tasks (Linux: crontab, Mac: crontab, or I think iCal can do it,
  Windows... I dunno). @p{»»}

  @p{««}So if you're a little bit geeky, you could arrange for "bitcoin
  sendtoaddress 1mJMYFAVORITECHARITY9R4 amount" to get run once a month.
  (just run bitcoin with the -server flag). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0091}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-16 17:52:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg3541@s{hash}msg3541
@section 3 {tx}

  @p{««}TESTcoins are maturing, and the TEST Faucet is open and giving out
  50 TESTcoins per visit: @s{(link)} @p{»»}

  @p{««}Feel free to grab some play money any time; there's no
  coins-per-IP-address limit, but you will have to solve the CAPTCHA if
  you revisit. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0092}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-17 14:13:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=434.msg3750@s{hash}msg3750
@section 3 {tx}

  @p{««}Here's how you can lose coins by backing up and restoring your
  wallet file: @p{»»}

  @p{««}Lets say you have one shiny 1,000 Bitcoin coin in your wallet (it's
  actually just a transaction for 1,000 bitcoins paid to a public key
  that's stored in your wallet). @p{»»}

  @p{««}You backup that file. @p{»»}

  @p{««}Now you spend 1 Bitcoin. Your shiny 1,000 BTC coin is broken into
  1BTC, plus 999BTC in change. That change is @p{(bf}given a new,
  different public key.@p{bf)} @p{»»}

  @p{««}Now if you restore your wallet file, Bitcoin sees that the 1,000BTC
  coin has been spent@p{--} 1BTC was sent somewhere, and the other 999BTC
  was sent somewhere else. Because you don't have the key for the 999BTC,
  it has no idea that those coins belong to you. @p{»»}

  @p{««}So they're lost. @p{»»}

  @p{««}Trying out alternative policies for handling change on the TEST
  network would be a good idea, in my opinion. @p{»»}

  @p{««}Maybe change transactions should always get signed with the same
  public key, so you wouldn't lose coins when restoring your wallet...
  although that would give you less privacy because it would tend to tie
  all your transactions together. @p{»»}

  @p{««}Maybe your wallet should get initially populated with 100 "change"
  addresses, with one randomly chosen as needed. And some super-geeky way
  of replacing them with another, new, 100 addresses. @p{»»}

  @p{««}Maybe there's an even better way of handling the "I lost BTC when I
  restored my wallet" problem; ideas? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0093}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-17 20:22:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=430.msg3794@s{hash}msg3794
@section 3 {tx}

  @s{quotedtext}

  @p{««}If that coin is one of the inputs to a later valid transaction,
  then it is spent and cannot be spent again. @p{»»}

  @p{««}That later transaction is the record that somebody spent the coin;
  it is signed with the private key, and that key (which Bitcoin keeps for
  you in your wallet) should be known only to the owner. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0094}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-17 20:44:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=401.msg3797@s{hash}msg3797
@section 3 {tx}

  @s{quotedtext}

  @p{««}Y'all know about @s{(link)}?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0095}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-18 16:42:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=430.msg4017@s{hash}msg4017
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. Whoever has the private key that can create that last
  signature can spend the coin@p{--} he or she (or them@p{--} eventually
  maybe as bitcoin clients add features) are the owner. @p{»»}

  @p{««}The transaction history isn't exactly a "chain" @p{--} multiple
  coins can get combined as input to a transaction (they're all "spent"),
  and multiple coins can get produced from a transaction (they're all
  "unspent" until they're used as the input to another transaction), so
  it's a more complicated network (I think of a chain as one link followed
  by another in a straight line). But it will all trace back to one or
  more 50 Bitcoin GENERATE transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0096}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-18 19:16:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=457.msg4042@s{hash}msg4042
@section 3 {tx}

  @s{quotedtext}

  @p{««}A few things make those 31.42BTC transactions unique: @p{»»}

    @p{(li}The timestamps in them will be different. @p{li)}

    @p{(li}The input transactions will be different (you can think of
    those as being different 'coins' going in to make the payment).
    @p{li)}

    @p{(li} And if the input transactions don't add up to exactly 31.42
    (and they probably won't), they'll have different output transactions
    for returning any change to Alice. @p{li)}

  @p{««}By the way: all that stuff is hashed together to give each
  transaction a unique 256-bit transaction ID (which you never see, but is
  used internally so Bitcoin can quickly figure out if it has already seen
  this transaction before).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0097}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-19 12:02:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4215@s{hash}msg4215
@section 3 {tx}

  @p{««}The Bitcoin Faucets (production and TEST) are now running with this
  change. @p{»»}

  @p{««}I was confused for a bit because the password is given LAST on the
  command line, but FIRST in the JSON-RPC params list. I agree that
  reading the command-line password from a file would be more convenient
  and more secure. @p{»»}

  @p{««}I'll try to do some research on how other projects tackle JSON-RPC
  authentication. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0098}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-19 12:30:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4221@s{hash}msg4221
@section 3 {tx}

  @p{««}The Transmission BitTorrent client does authenticated JSON-RPC; see
   "Remote Control" section of: @p{brk} @s{(link)} @p{»»}

  @p{««}E.g. setting.json file might look like: @p{»»}

  @s{code}

  It uses @p{(link}HTTP 'basic' authentication@p{link)} (Authorization:
  basic base64(username:password) in the HTTP headers). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0099}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-19 15:20:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4248@s{hash}msg4248
@section 3 {tx}

  @p{««}After further research... I think the Transmission approach,
  combined with the existing "only allow connections from 127.0.0.1" is a
  good short/medium-term solution. @p{»»}

  @p{««}Putting the username:password in a settings.json file in the
  Bitcoin directory aught to work nicely (since Bitcoin can already parse
  JSON). And keeping the authentication stuff off the command line and in
  the HTTP headers instead of the JSON request params is nice and clean.
  @p{»»}

  @p{««}Long term, the "right" way to do authenticated, secure JSON-RPC is
  with client-side certificates and https. But that looks like it would be
  a lot of work to implement and a @p{(link}big learning curve@p{link)}
  for users to figure out how to generate client-side certificates and how
  to get both sides of the JSON-RPC connection using them. And I'm not
  even certain a full-blown client certificate solution would solve the
  problem of malicious Javascript making JSON-RPC requests via
  XMLHttpRequests to localhost; if the user installed the client
  certificate in the browser (because maybe there was a nifty
  JSON-RPC-powered web front-end to controlling Bitcoin), would the
  browser automatically send the client certificate if a malicious website
  made requests? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0100}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-19 15:52:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=476.msg4257@s{hash}msg4257
@section 3 {tx}

  @s{quotedtext}

  @p{««}I think that's a politically correct way of saying "we accept food
  stamps." Try going in with a fistful of Euros and see what happens.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0101}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-19 16:58:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4284@s{hash}msg4284
@section 3 {tx}

  @s{quotedtext}

  @p{««}You ask hard questions! Most common: probably @p{(link}Windows
  INI@p{link)} files, because Windows is most common OS. @p{»»}

  @p{««}I'd lobby for using JSON; it's (mostly) a subset of YAML (which is
  a common choice for config files), so any JSON or YAML parser will read
  it. @p{»»}

  @s{quotedtext}

  @p{««}I think the only big advantage is that it keeps authentication
  where it belongs in the transport layer, so if, in the future, you
  @p{(bf}do@p{bf)} want to go with full-fledged HTTPS with certificates
  the API doesn't have to change. @p{»»}

  @s{quotedtext}

  @p{««}No, I just confused "command" with "parameter", and did this: @p{»»}

  @s{code}

  @p{««}... that works. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0102}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-20 01:07:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=488.msg4400@s{hash}msg4400
@section 3 {tx}

  @s{quotedtext}

  @p{««}There are already a few places in the source code where that is
  done. @p{»»}

  @s{quotedtext}

  @p{««}I think Satoshi's done a darn good job of anticipating future
  needs. The wire protocol and database serialization formats both have
  version numbers, as do bitcoin addresses. The core transaction mechanism
  is @p{(it}very@p{it)} flexible (I worry that it might be too flexible,
  but that's why we've got the TEST network to see if we can break it).
  @p{»»}

  @p{««}I can't think of anything simple that would make it more
  future-proof. If you're worried about SHA256 getting broken or the
  21quadrillion Bittiestcoins not being enough... then you worry too much.
  Stop worrying, you'll just suffer from analysis paralysis and get
  nothing done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0103}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-20 13:31:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=496.msg4450@s{hash}msg4450
@section 3 {tx}

  @p{««}See the "@p{(link}Bitcoin snack machine@p{link)}" discussion. @p{»»}

  @p{««}Real-world, ordinary-sized transactions should wait a few seconds
  for the transaction to propagate across the network. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0104}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-20 16:59:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=496.msg4488@s{hash}msg4488
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm not personally notified, no... @s{wink} But if I have a Bitcoin
  client connected to the network then yes, it (along with all the other
  connected clients) should be sent every transaction shortly after they
  happen. It has to@p{--} it might be generating blocks, and the whole
  point of block generation is to record the valid transactions the client
  has seen that haven't been included in a previous block. @p{»»}

  @p{««}There's a discussion in @p{(link}this thread@p{link)} of how likely
  it is that an attacker could "split the network" to successfully
  double-spend coins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0105}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-21 12:11:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4709@s{hash}msg4709
@section 3 {tx}

  @p{««}I think there's no such thing a a "typical" settings file on Linux!
  @p{»»}

  @p{««}I just did a quick survey of 20 .conf files in /etc on my debian
  system, and found: @p{»»}

    @p{(li}1 file used "key value" @p{li)} @p{(li}5 used "key=value"
    (actually, a couple were "key = value", allowing whitespace around the
    "=") @p{li)} @p{(li}14 did their own thing. @p{li)}

  @p{««}The 14 that did their own thing were all over the map; from
  one-value-per-line to "key:value" to full-blown XML. @p{hash} is the
  universal comment character in the Linux world. @p{»»}

  @p{««}My vote would be for: @s{code} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0106}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-21 14:53:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=510.msg4738@s{hash}msg4738
@section 3 {tx}

  @p{««}I sent him 10 Bitcoins, and my hair grew back! @p{»»}

  @p{««}So I sent him 20 Bitcoins, and I won the lottery! @p{»»}

  @p{««}No Joke!!!! Now I'm hairy and rich!!!! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0107}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-21 15:01:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=479.msg4740@s{hash}msg4740
@section 3 {tx}

  @p{««}You can still generate bitcoins, just don't run bitcoind or bitcoin
  -server or bitcoin -daemon on machine that you use to browse the Web.
  @p{»»}

  @p{««}As sirius says, if you do you could browse to a website that
  empties your Bitcoin wallet without your knowledge or permission.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0108}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-21 16:10:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=479.msg4759@s{hash}msg4759
@section 3 {tx}

  @p{««}chroot: won't protect you. @p{»»}

  @p{««}Running as a separate VM: I think will protect you. But I thought
  browsers wouldn't allow XMLHTTPRequests to "localhost" from web pages
  fetched from the web, so my advice would be to test it. See if you can
  talk to the Bitcoin daemon from another VM on the same machine by
  running "bitcoind getinfo" or "bitcoin getinfo" on the non-bitcoin-vm.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0109}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-22 01:11:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4908@s{hash}msg4908
@section 3 {tx}

  @p{««}I volunteered to implement this, and made good progress today.
  Satoshi: I should have patches for you tomorrow. @p{»»}

  @p{««}Done: teach Bitcoin to read settings from
  {BITCOIN_DIR}/bitcoin.conf file, and added
  -conf=path_to_config_file.conf command-line option. @p{brk} Done: teach
  Bitcoin RPC to require HTTP Basic authentication, and reject requests
  with the wrong username/password. @p{»»}

    @p{(li}TODO: teach Bitcoin command-line RPC to add the Authorization:
    header. You won't have to give the username/password when controlling
    bitcoin from the command line, it'll read them from the bitcoin.conf
    file and Do the Right Thing. @p{li)}

    @p{(li}TODO: dialog box or debug.log warning if no
    rpc.user/rpc.password is set, explaining how to set. @p{li)}

    @p{(li}TODO: limit password guessing attempts if the rpc.password is
    @p{lt} 15 characters long. @p{li)}

    @p{(li}TODO: update the JSON-RPC wiki page @p{li)}

  @p{««}After all that is done and I've sent patches to Satoshi, I'm going
  to add a couple more things to bitcoin.conf : @p{»»}

  @s{code}

  @p{««}With the existing -datadir option, that'll make it easier for me to
  run multiple bitcoins on one box. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0110}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-22 01:51:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg4918@s{hash}msg4918
@section 3 {tx}

  @p{««}I've implemented it so that all the command-line options can also
  be specified in the bitcoin.conf file. @p{»»}

  @p{««}Options given on the command line override options in the conf
  file. But I need to do more testing, especially with the "multiargs"
  options like "addnode". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0111}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-22 12:47:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=505.msg5012@s{hash}msg5012
@section 3 {tx}

  @p{««}I think this won't work because there is not a one-to-one
  relationship between "unspent transactions" and public keys. @p{»»}

  @p{««}Example: I start with 0 BTC. Two people each send me 50, to the
  same receiving address "GavinPubKey". @p{»»}

    @p{(li}Balance Sheet: GavinPubKey: 100 @p{li)}

  @p{««}I spend the first one: @p{»»}

    @p{(li}Balance Sheet: GavinPubKey: 50 @p{li)}

  @p{««}If I'm dishonest, what stops me from waiting a few months and then
  spending that first 50 again instead of spending that second 50?
  Double-spending that first 50 will look like a perfectly valid
  transaction to any nodes using the balance sheet method who weren't
  around to see the first time I spent it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0112}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 02:25:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=535.msg5181@s{hash}msg5181
@section 3 {tx}

  @p{««}TxIn: prev(82df...6428:1) means the second TxOut of transaction
  82df...something...6428 (it abbreviates the full 256-bit transaction
  hash and starts counting at zero). @p{»»}

  @p{««}To see that transaction: @p{»»}

  @s{code}

  @p{««}This looks like bitnickels coins coming out of the Bitcoin Faucet.
  The transaction before THAT is: @p{»»}

  @s{code}

  @p{««} To compute the net transaction value, just add up the values of
  all the TxOuts; they have to equal the sum of all the TxIns (well,
  unless there are @p{(link}transaction fees@p{link)}). So for that first
  transaction, 66.07+0.05 = 66.12 (which is, indeed, bfb0...cd16:1) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0113}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 15:11:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg5296@s{hash}msg5296
@section 3 {tx}

  @p{««}I've updated the @p{(link}RPC wiki page@p{link)} for how the
  password stuff will work in Bitcoin 0.3.3. @p{»»}

  @p{««}One nice side effect: you can prepare for the changes now; create a
  bitcoin.conf file with a username and password and modify your JSON-RPC
  code to do the HTTP Basic Authentication thing. Old code will just
  ignore the .conf file and the Authorization: HTTP header. @p{»»}

  @p{««}Question for everybody: should I add a section to the wiki page
  describing, in detail, how to do HTTP Basic authentication? PHP and
  Python make is really easy@p{--} just use the
  @p{(link}@s{(link)}@s{at}host:port/@p{link)} URL syntax. I don't want to just
  duplicate the HTTP Basic authentication Wikipedia page. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0114}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 17:56:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg5342@s{hash}msg5342
@section 3 {tx}

  @s{quotedtext}

  @p{««}OK, I did Python and PHP, and I added what I know about Java. Can
  somebody who has used Java JSON-RPC update the wiki page with a working
  example? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0115}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 18:51:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg5357@s{hash}msg5357
@section 3 {tx}

  @s{quotedtext}

  @p{««}I strongly disagree; software should be secure by default, and
  running bitcoind without a password (or bitcoin -server) is definitely
  NOT secure. @p{»»}

  @p{««}I just don't see somebody saying "Man, Bitcoin sucks because I have
  to add a password to a configuration file before running it as a
  daemon." I @p{(bf}can@p{bf)} see somebody saying "Man, Bitcoin sucks
  because I accidently ran it with the -server switch and somebody stole
  all my money." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0116}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 19:10:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=286.msg5360@s{hash}msg5360
@section 3 {tx}

  @p{««}What's funny? @p{»»}

  @p{««}A server lying about whether or not your transactions are valid
  would be like your ISP lying about whether or not your HTTP requests are
  valid or not. @p{»»}

  @p{««}If they lie, you'll very quickly find another service provider (or
  download a Bitcoin iPhone app that doesn't suck and say that your
  transactions are invalid). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0117}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 21:18:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg5390@s{hash}msg5390
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, that's right, rpcpassword is only required if you use -server
  or -daemon or bitcoind (I just tested to be sure). @p{»»}

  @p{««}RE: what if the programmer can't figure out how to make their
  legacy COBOL code do HTTP authentication? @p{brk} Then I think another
  config file setting to explicitly turn off RPC authentication would be
  better than a magical "if you set a blank rpcpassword then that turns
  off authentication." But I wouldn't implement that until somebody really
  does have a problem or until we have more than one way of doing the
  authentication (maybe https someday...). @p{»»}

  @p{««}lachesis: is supporting HTTP Basic Authentication a problem for
  you? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0118}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-23 21:42:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=549.msg5393@s{hash}msg5393
@section 3 {tx}

  @p{««}If a philanthropist wants to give away bitcoins to the bitcoin
  community, I'd be happy to reset the Bitcoin Faucet rules to whatever
  the philanthropist would like. @p{»»}

  @p{««}Could be: donate 10,000 Bitcoins and then have the Faucet
  distribute 10 per IP address (regardless of whether or not they got
  coins from the Faucet before) until they're gone. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0119}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-24 01:44:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=555.msg5424@s{hash}msg5424
@section 3 {tx}

  @p{««}They key bits of code are: @p{»»}

  @s{code}

  @p{««}pchMessageStart are the four magic bytes, and those are written
  with FLATDATA. @p{»»}

  @p{««}The CBlock itself is written by @p{lt}@p{lt} *this, and that's done
  by the IMPLEMENT_SERIALIZE in main.h: @p{»»}

  @s{code}

  @p{««} The READWRITE macros Do The Right Thing, reading in or writing out
  the members in a machine-independent way. @p{»»}

  @p{««}See @s{(link)} for simplified Python code that can dump out
  transactions and blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0120}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-25 14:20:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=566.msg5692@s{hash}msg5692
@section 3 {tx}

  @p{««}Is there something simpler than CMake that would work? @p{»»}

  @s{code}

  @p{««}Adding Yet Another Multi-Megabyte Dependency to build bitcoind
  seems like a backwards step to me. @p{»»}

  @p{««}What's the most popular build solution for other small-ish,
  successful open source projects? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0121}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-25 14:39:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=566.msg5693@s{hash}msg5693
@section 3 {tx}

  @p{««}Answering my own questions: @p{(link}Project using CMake@p{link)}
  @p{»»}

  @p{««}I looked at 'weechat'; they're migrating from gnu autotools to
  cmake (still support both, but recommend cmake). @p{»»}

  @p{««}So another +1 for cmake.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0122}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-25 16:14:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=567.msg5702@s{hash}msg5702
@section 3 {tx}

  @p{««}Well, at least do it on the TEST network FIRST! @p{»»}

  @p{««}If you manage to break the TEST network, it's a pretty good bet
  that you'll be able to break the production network. If it doesn't break
  the TEST network, then I'd say go ahead and run against the production
  network to look for "scaling up" problems. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0123}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-25 21:38:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg5768@s{hash}msg5768
@section 3 {tx}

  @s{quotedtext}

  @p{««} Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL
  in the rpc.cpp/EncodeBase64 function: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0124}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-26 17:16:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=231.msg5903@s{hash}msg5903
@section 3 {tx}

  @s{quotedtext}

  @p{««}I've been tempted... but no, I'm more interested in doing web-based
  Bitcoin apps, and extending the existing C++ implementation's JSON-RPC
  API is a whole lot less work than re-implementing the whole shebang.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0125}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-27 14:08:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=589.msg6034@s{hash}msg6034
@section 3 {tx}

  @p{««}I've been working on adding -port= / -rpcport= command line /
  config file options to bitcoin. The idea is to let you run multiple
  copies of bitcoind on one machine; I need this because I'm planning on
  having at least two Bitcoin-related web services (the Bitcoin Faucet and
  a service to be named later), I want them to have completely separate
  wallets, but I don't want to rent multiple servers to host them. @p{»»}

  @p{««}Usage looks like this: @p{»»}

  @s{code}

  @p{««} Satoshi pointed out that allowing bitcoin/bitcoind to run on a
  non-standard port could be dangerous, because if misconfigured two
  bitcoins might both open and write to the same database. To prevent
  that, the @p{lt}datadir@s{gt}/db.log file is used as a lock so only one
  bitcoin can access the same datadir at a time (uses
  boost::interprocess::file_lock, which is purported to be cross-platform
  and well-behaved, even if bitcoin crashes). @p{»»}

  @p{««}Issues that came up as I was doing this: @p{»»}

  @p{««}I left a call to wxSingleInstanceChecker in the Windows GUI code,
  so no multiple-gui-bitcoins-listening-on-different-ports on Windows. I
  don't do Windows... @p{»»}

  @p{««}I didn't bother making the error handling graceful if you point two
  bitcoins at the same datadir (you get a runtime exception "Cannot lock
  db.log, is bitcoin already running?"). @p{»»}

  @p{««}Patches are at @s{(link)}; I've only tested on Linux so far,
  anybody willing to try this on Windows? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0126}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-27 14:36:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=563.msg6037@s{hash}msg6037
@section 3 {tx}

  @s{quotedtext}

  @p{««}Before the last two difficulty adjustments it took my (4-year-old)
  mac laptop two weeks to generate any bitcoin. @p{»»}

  @p{««}So after the adjustments, I estimate it could take it 1-2
  @p{(bf}months@p{bf)} to generate any. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0127}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-28 13:40:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=601.msg6190@s{hash}msg6190
@section 3 {tx}

  @p{««}Does it work if you specify the full path? e.g.
  -datadir=/home/psyvenrix/datadir2 ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0128}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-28 15:18:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=604.msg6206@s{hash}msg6206
@section 3 {tx}

  @p{««}I get: @p{»»}

  @s{code}

  @p{««}... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc
  version 4.2.1). @p{»»}

  @p{««}I fixed it by adding -DCRYPTOPP_DISABLE_ASM to my makefile; perhaps
  somebody with more experience compiling C++ on a Mac can figure out a
  better fix. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0129}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-28 18:15:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=605.msg6243@s{hash}msg6243
@section 3 {tx}

  @p{««}If you include a double-spent transaction in a block you generate,
  then that block will be rejected and you don't get your 50BTC
  reward.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0130}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-28 21:40:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=604.msg6274@s{hash}msg6274
@section 3 {tx}

  @s{quotedtext}

  @p{««}I built a TEST-network bitcoind with the SVN r115 changes merged
  in, and yes, after that one change it's been happily generating coins
  all afternoon. @p{brk} I don't use the stock makefile.osx, though@p{--}
  I setup the dependency directory structure a little differently (for no
  really good reason). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0131}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-29 16:28:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=615.msg6418@s{hash}msg6418
@section 3 {tx}

  @s{quotedtext}

  @p{««} Are you still downloading the block chain? If you don't already
  have all 70,000+ blocks in the block chain, then you transaction won't
  show up as confirmed until you catch up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0132}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-29 18:49:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=617.msg6447@s{hash}msg6447
@section 3 {tx}

  @s{quotedtext}

  @p{««}He/she/they want an easier way for The Crowd to control The
  Policy@p{--} right now, if you know enough C++ to modify and compile
  your own version of Bitcoin and can convince enough other people to use
  your version, then you can change Policy. @p{»»}

  @p{««}Allowing everybody to tweak Policy and having some sort of
  mechanism that figures out what "everybody" wants to do is an
  interesting idea. I have no idea how you could actually make it work,
  and it would open up a whole other can of potential security problems
  (what if somebody controls a bunch of IP addresses and decides to "vote"
  for a policy that benefits them? or can you tie the policy changes to
  proof-of-work somehow? How do you aggregate what "everybody" thinks in a
  non-spoofable way? etc etc etc)... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0133}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 12:53:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=461.msg6639@s{hash}msg6639
@section 3 {tx}

  @s{quotedtext}

  @p{««}That second ./bitcoind getinfo has to be: @p{»»}

  @s{code}

  @p{««}... otherwise it will use the default config file and datadir.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0134}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 13:18:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg6642@s{hash}msg6642
@section 3 {tx}

  @p{««}Couple of quick suggestions: @p{»»}

  @p{««}Using the key name "class" will cause problems for, at least,
  JavaScript, and probably other languages where "class" is a reserved
  word. "type" or "variety" or some other synonym will cause fewer
  problems later. @p{»»}

  @p{««}Or, maybe better, get rid of that field and just report credits as
  positive numbers and debits as negative. And add a separate "generated"
  field (boolean true or false). @p{»»}

  @p{««}Since each entry refers to a transaction, I'd suggest adding a
  "tx_id" SHA256 hex-encoded transaction id. Then listtransactions would
  play nicely with the refundtransaction JSON-RPC extension (and maybe a
  future gettransactiondetails that let you get transaction parents, which
  block the transaction was in, and so on). @p{»»}

  @p{««}Code to get that would look something like: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0135}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 14:28:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=632.msg6656@s{hash}msg6656
@section 3 {tx}

  @p{««}Speaking of the network... @p{brk} ... is there any really robust,
  generic, low-latency, open source p2p network "middleware" out there?
  @p{»»}

  @p{««}I think using protocol buffers as the serialization format is a
  good idea, but I don't think just switching to protocol buffers "buys"
  enough to be worth the effort (at least not now, when transaction volume
  is low). @p{»»}

  @p{««}I'd like to see some experimenting with running bitcoin on top of a
  different networking layer (and use protocol buffers, too). Is there a
  p2p network that is designed to be extremely highly reliable and
  difficult to infiltrate or attack with malicious nodes? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0136}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 17:09:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=643.msg6677@s{hash}msg6677
@section 3 {tx}

  @p{««}The good news is the TEST network is doing its job@p{--} the
  problem patched by the 0.3.6 release (invalid transactions accepted as
  valid) was implemented and demonstrated on the TEST network. @p{»»}

  @p{««}The bad news is that means the TEST network block chain split
  yesterday. If you are, or were, running a release prior to 0.3.6 on the
  TEST network, you've got bad blocks in your blkindex.dat and blk0001.dat
  files. @p{»»}

  @p{««}So, you need to: @p{brk} 1. Shut down bitcoin or bitcoind @p{brk}
  2. Remove the blkindex.dat and blk0001.dat (in ~/.bitcoinTEST or
  ~/Library/Application Support/BitcoinTEST or %APPDATA%\BitcoinTEST)
  files. @p{brk} 3. Be sure you're upgraded to 0.3.6 @p{brk} 4. Run
  bitcoin/bitcoind, and you'll download the "good" block chain. @p{»»}

  @p{««}Any blocks you generated after the bad blocks are invalid, so if
  you were busily generating blocks on the TEST network in the last couple
  of days... sorry, that play money is gone. @p{»»}

  @p{««}Transactions that you made may or may not make it to the new block
  chain, depending on whether or not they originated from invalid coins
  (any coins generated after the bad blocks are invalid). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0137}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 17:55:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=640.msg6681@s{hash}msg6681
@section 3 {tx}

  @s{quotedtext}

  @p{««}I just updated my git "svn" branch with r116-119, and also merged
  it against 'master'. @p{»»}

  @p{««}The @p{(link}git network diagram@p{link)} showing what I done did
  is kinda pretty. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0138}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-30 19:48:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg6709@s{hash}msg6709
@section 3 {tx}

  @s{quotedtext}

  @p{««}It's pretty common to turn maps into objects, so you can use syntax
  like: @s{code} ... instead of @s{code}. Especially if you're doing
  something like passing the data into a templating system (which may ONLY
  understand the object.field syntax). @p{»»}

  @p{««}And foo.class just doesn't work out nicely.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0139}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-31 13:35:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg6807@s{hash}msg6807
@section 3 {tx}

  @p{««}Can you be more specific about where your build fails? Is it in the
  new code to support the -port / -rpcport options (which I should have
  put on a different git branch) ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0140}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-31 13:58:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg6815@s{hash}msg6815
@section 3 {tx}

  @s{quotedtext}

  @p{««}Cool! Hope you don't mind, I added it to my github network as a
  'feature' branch. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0141}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-31 17:43:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg6832@s{hash}msg6832
@section 3 {tx}

  @p{««}That IS part of the new -port / -rpcport code (I use
  boost::interprocess::file_lock to make sure bitcoins running on
  different ports don't try to use the same wallet/blkindex/etc files).
  @p{»»}

  @p{««}I'll create an svnTEST branch that omits those changes, and will
  always be just a TEST-network version of the latest svn trunk. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0142}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-31 18:33:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg6833@s{hash}msg6833
@section 3 {tx}

  @p{««}svnTEST branch is up on github. @p{»»}

  @p{««}I also uploaded just the production-bitcoin-to-TEST-network-bitcoin
  patches to github, at: @s{(link)} @p{brk} ... so: @s{code} ... should
  patch production network source code to TEST network. And: @s{code} ...
  will go the other way.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0143}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-07-31 19:47:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=643.msg6847@s{hash}msg6847
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yep, you're right. The good fork is longer than the bad one now;
  the last ORPHAN BLOCK my TEST bitcoind got was about 20 hours ago. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0144}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-03 11:44:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=195.msg7212@s{hash}msg7212
@section 3 {tx}

  @s{quotedtext}

  @p{««}I don't think you need scripts to do something like that. @p{»»}

  @p{««}Just send a bitcoin to yourself, and then declare that transaction
  is the "root transaction for My Valuable Asset." @p{»»}

  @p{««}You'd need a custom client that only accepted or spent transactions
  that could be entirely traced back to that Root Transaction (not hard,
  all transactions can be tracked back). And shows fractions of that coin
  as units of your custom currency. And you'd probably want to make some
  other changes so your users didn't accidently (or purposely) mix Your
  Valuable Asset coin with regular bitcoins (like a custom wallet and
  different scheme for generating payment addresses). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0145}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-03 18:38:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=661.msg7293@s{hash}msg7293
@section 3 {tx}

  @s{quotedtext}

  @p{««}Transactions won't disappear if they're valid. They'll just move to
  the longer block chain. @p{»»}

  @p{««}Invalid transactions would be somebody trying to double-spend
  across the split chains (which would be tricky@p{--} you'd have to run a
  modified client, or copy your wallet to a machine working on the other
  block chain). @p{»»}

  @p{««}Or if the split lasted long enough (more than 100 blocks),
  transactions that involve generated coins on the shorter chain would be
  invalid at the merge. @p{»»}

  @p{««}For shorter splits, immature generated coins on the shorter chain
  will disappear when the chains merge, but that would be about the worst
  consequences for honest users (unless you were unlucky enough to get an
  invalid coin from somebody trying to cheat). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0146}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-03 18:56:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=689.msg7299@s{hash}msg7299
@section 3 {tx}

  @s{quotedtext}

  @p{««}Can you be more specific about which JSON libraries don't provide
  Content-Length ? It'd be nice to document that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0147}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-03 22:52:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=689.msg7358@s{hash}msg7358
@section 3 {tx}

  @s{quotedtext}

  @p{««}Perl's LWP module definitely sets the Content-Length header. I
  would've been surprised if it didn't, since it is required by HTTP 1.0
  and the HTTP 1.1 spec says clients 'SHOULD' set it. @p{»»}

  @p{««}After some struggle, I got the first @p{(link}JSON::RPC
  library@p{link)} at CPAN to work: @p{»»}

  @s{code}

  @p{««}The struggle was setting the realm to 'jsonrpc' (it is fussy about
  that). I'll document that on the wiki. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0148}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-04 11:58:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg7454@s{hash}msg7454
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... unless B started with zero bitcoins. Then B is stuck; she
  can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin
  'change' transaction, which would trigger the 0.01BTC fee, which they
  can't pay (because they only have 1.0000000001). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0149}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-04 12:55:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg7459@s{hash}msg7459
@section 3 {tx}

  @s{quotedtext}

  @p{««}The rule is "if any TxOut (output) has a value of less than 0.01
  bitcoins, charge a 0.01 fee": @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0150}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-04 20:40:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=704.msg7575@s{hash}msg7575
@section 3 {tx}

  @p{««}I just shut down freebitcoins.appspot.com; it looks like somebody
  in Spain is being a jerk and getting a new IP address, bitcoin address,
  and solving the captcha. Over and over and over again: @p{»»}

  @s{code}

  @p{««}Those IP addresses all map to Telefonica de Espana. If it was you:
  give them back, please: @s{btcaddress} @p{»»}

  @p{««}Now that 5 bitcoins is worth a fair bit, I'm thinking I need more
  cheating countermeasures. I can think of four things to try: @p{»»}

    @p{(li}1. Rate limit based on the first byte of the IP address (79. or
    81. in this case). @p{li)}

    @p{(li}2. Rate limit based on the USER-AGENT string ("Opera/9.8..." in
    this case). @p{li)}

    @p{(li}3. Rate limit based on last two domains of reverse DNS lookup
    of the IP address (rima-tde.net in this case). @p{li)}

    @p{(li}4. Make the standard amount given away 0.5 Bitcoins (Bitcoins
    have gone up 10 times in value since I started the Faucet). @p{li)}

  @p{««}If you get rate limited, you'll get a message that asks you to try
  again tomorrow. @p{»»}

  @p{««}BitcoinFX: thanks again for the donation to the faucet; I'm going
  to drain the Faucet below 500 coins temporarily, and will refill it with
  your donation after the new cheating countermeasures are in place. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0151}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-05 02:06:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=704.msg7616@s{hash}msg7616
@section 3 {tx}

  @p{««}Thanks for all the ideas! @p{»»}

  @p{««}First: I'm definitely going to drop from 5 BTC; I think I'll go all
  the way down to 0.50 BTC (rather than do 1 or 2). Giving away a
  percentage of how much the faucet has is an interesting idea, but I want
  it to be as simple as possible. @p{»»}

  @p{««}Second: I really don't want to make getting coins from the Faucet a
  whole heavy-weight "register and check your email and yada yada yada."
  @p{»»}

  @p{««}But I do like the idea of adding an extra hurdle for
  'suspicious-looking' behavior. So I'm leaning towards doing some fuzzy
  browser fingerprinting combined with rate-limiting and, if you look
  suspicious or the fountain has been giving away a larger-than-usual
  number of coins, require that you login with your google account before
  getting any coins. No google account: no coins. @p{»»}

  @p{««}It is hard to create lots of google accounts; they're requiring
  either phone or SMS account verification these days... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0152}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-05 02:11:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=704.msg7617@s{hash}msg7617
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yeah, I shoulda anticipated problems when Bitcoins went from 0.005
  USD each to 0.06 each. If it takes somebody two minutes to go through
  the "get a new IP, get a new BC address, solve the captcha" process then
  they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which,
  if you're unemployed, bored, and/or 13 years old is easy money. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0153}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-05 02:19:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75.msg7619@s{hash}msg7619
@section 3 {tx}

  @s{quotedtext}

  @p{««}Hah! While I was typing this, Kiba said essentially the same
  thing... @p{»»}

  @p{««}We are all rich because we have computers and the Internet and
  Wikipedia and other wonders the world has never seen before. @p{»»}

  @p{««}There @p{(bf}is@p{bf)} absolute wealth. We are healthier and
  wealthier and live longer than any previous generation, and that's a
  wonderful thing.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0154}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-05 18:40:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=703.msg7720@s{hash}msg7720
@section 3 {tx}

  @p{««}Ummm, the command-line RPC is implemented on @p{(bf}top@p{bf)} of
  the JSON-RPC mechanism. @p{»»}

  @p{««}So if the command-line RPC is working on your machine, then the
  JSON-RPC is, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0155}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-06 00:32:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287.msg7761@s{hash}msg7761
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm thoroughly confused on what, exactly, you're proposing. @p{»»}

  @p{««}I want to make a 100 Bitcoin transaction to you. @p{»»}

  @p{««}You're proposing that I need to pay a "transmit fee" ... which is
  paid to who and does what, exactly? @p{»»}

  @p{««}If I pay it to A, B, and C, does that mean they rebroadcast the
  transaction to everybody they're connected to? Do they, in turn, pay
  transmit fees to the nodes they're rebroadcast it to? What stops them
  from saying "Thank you very much for the transmit fee" and cheating
  (drop my transaction on the floor)? @p{»»}

  @p{««}Satoshi's proposal that all transaction carry a minimum fee to
  cover network overhead makes sense; whoever generates the block with the
  transaction gets the fee. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0156}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-06 19:36:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=723.msg7940@s{hash}msg7940
@section 3 {tx}

  @s{quotedtext}

  @p{««}Interesting idea. @p{»»}

  @p{««}So, lets see, I create a transaction to pay you (say) 100 of my
  newly minted bitcoins. @p{»»}

  @p{««}That'll be a transaction with two 50BTC TxIns (signed by me,
  pointing to two mature GENERATE transactions somewhere in the block
  chain) and one 100BTC TxOuts. @p{»»}

  @p{««}You want to make sure I haven't double-spent those TxIns, so
  instead of flooding the network with that transaction you find the hash
  of the two GENERATE transactions and send two queries down into the DHT
  network: "Hey, here's a transaction, tell me if it is valid." They say
  "yup", and then... what? Include it in any blocks they're lucky enough
  to generate? Broadcast it to everybody (which'd be no better than the
  current scheme) or some subset of the DHT network (what subset?)? @p{»»}

  @p{««}How do you know that you won't get a different answer to "is this
  transaction valid" if you ask again in 10 minutes when the network
  topology might have changed? @p{»»}

  @p{««}I don't know much about DHT networks and how they manage to keep
  reliable information when nodes may be coming and going (or buggy or
  malicious). How would it work? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0157}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-06 22:12:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=737.msg7990@s{hash}msg7990
@section 3 {tx}

  @p{««}Some random Friday afternoon brainstorming: could you print out
  bitcoins to function as user-created paper money? @p{»»}

  @p{««}@p{(link}QR code@p{link)} could be used to encode a transaction
  hash and a transaction signature on a piece of paper (along with a
  human-readable amount). A bitcoin client could print out coins that are
  in your wallet and marks them as "PRINTED" (so you don't accidentally
  spend them@p{--} there would probably be a way of recovering them in
  case the paper versions were lost or stolen, and they'd automatically
  get removed when the paper versions were spent). @p{»»}

  @p{««}Give that piece of paper to a merchant connected to the Bitcoin
  network and they can scan it and transfer the coins into their wallet.
  They should then destroy the paper, because that transaction is spent.
  @p{»»}

  @p{««}Double-spending would be nearly impossible, because once you give
  the paper to the merchant you lose control over exactly when they submit
  it to the network to be verified. @p{»»}

  @p{««}The only problem I see is how the merchant gives you your change.
  The merchant could print out the change, but you'd have to trust that
  they were giving you valid, unspent coins, unless you have a device
  connected to the network that could verify them (but that's dumb,
  because if you do have such a device why bother with paper bitcoins?).
  We trust merchants not to give us counterfeit dollars... I wonder if
  fear of loss of reputation would be enough to keep them honest when
  giving paper bitcoins as change... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0158}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-06 23:32:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=723.msg8013@s{hash}msg8013
@section 3 {tx}

  @s{quotedtext}

  @p{««} What happens when they disagree about which transaction happened
  first? Majority rule? Who decides what the majority is, and can it
  change if 4 of the five nodes leave the network and are replaced by
  another 5 nodes? @p{»»}

  @p{««}And if I know that I'm going to create a large transaction, can I
  do some work precomputing node IDs such that the transaction (which I
  haven't yet sent out) will hash to nodes that I control? If I control
  all the nodes storing the transaction, then I can just answer "yes,
  absolutely, that transaction is valid and hasn't been double-spent..."
  @p{»»}

  @p{««}The brilliant insight behind bitcoin is the distributed
  timestamping mechanism; everybody agrees on an order of transactions. I
  don't see how your scheme solves that problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0159}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-07 01:20:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=723.msg8035@s{hash}msg8035
@section 3 {tx}

  @s{quotedtext}

  @p{««}Now I'm confused again. I thought your scheme didn't have blocks,
  just transactions. What do you mean, whoever solves "the block" first?
  @p{»»}

  @s{quotedtext}

  @p{««}But standard DHTs are typically used to store chunks of MP3s or
  movies, indexed by a torrent file that has the hash for every piece. So
  it is easy for me to tell whether or not I'm getting bad data from any
  particular DHT node. I don't have to trust them. @p{»»}

  @s{quotedtext}

  @p{««}Huh? Lets say the network has 10,000 nodes in it. I query the
  network to find the network node closest to a transaction that I want to
  double-spend. @p{»»}

  @p{««}So I generate a private key. It has about a 1 in 10,000 chance of
  being closer than the current closest node. So I keep generating private
  keys until I have 5 that are closer. It's too late for me to figure out
  the odds, but lets say I generate 100,000 private keys, I'm pretty darn
  likely to find 5. My wimpy laptop can generate at LEAST 100 ECC
  keys/second, so in under 20 minutes it could generate 100,000. @p{»»}

  @p{««}I create 5 nodes with those keys (telling the rest of the network
  "honest, folks, I chose those keys RANDOMLY...") and I've won. @p{»»}

  @s{quotedtext}

  @p{««}I'm not trying to generate a transaction with a particular hash,
  I'm trying to generate node ids that are "closer" to that transaction's
  hash than any other node currently on the network. That's much easier.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0160}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-07 11:52:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=723.msg8078@s{hash}msg8078
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, not at all. Like I said when I jumped into this thread, I think
  using a DHT network to somehow distribute the work is a very interesting
  idea, it just seems to me any solution that partitions the network will
  be more vulnerable to attacks that insert malicious nodes. I think it
  would be fantastic to come up with less resource-intensive solution that
  actually works. @p{»»}

  @p{««}How does Freenet generate node IDs? The only info I see in the
  latest Freenet paper is: @p{»»}

  @s{quotedtext}

  @p{««}.... and: @s{quotedtext}

  @p{««}...which doesn't sound like it would work very well for
  Bitcoin.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0161}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-10 21:26:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=721.msg8601@s{hash}msg8601
@section 3 {tx}

  @s{quotedtext}

  @p{««}Sure, in exactly the same way the existence of credit cards
  motivates behavior of stealing credit card numbers from innocent credit
  card users. @p{»»}

  @p{««}Or the existence of bank accounts motivates hackers to try to break
  into your system to find out your bank account number. @p{»»}

  @p{««}Or the existence of cars motivates some people to steal gasoline
  from innocent service station owners. @p{»»}

  @p{««}I believe the benefits of Bitcoin will outweigh the harm, and I
  further believe that I @p{(bf}am@p{bf)} capable of making that moral
  judgment. I might be wrong, and I might regret I ever got involved, but
  if I only ever did things that I was 100% certain were going to work out
  for the best I would never accomplish anything new and interesting.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0162}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-10 21:49:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=779.msg8607@s{hash}msg8607
@section 3 {tx}

  @s{quotedtext}

  @p{««}Eventually the largest merchants and money exchangers will control
  what is "standard" bitcoin. @p{»»}

  @p{««}Take the "50-coiners" scenario, and imagine that they manage to get
  75% of the CPU power on their side. @p{»»}

  @p{««}But imagine that the biggest merchants and money exchangers are
  more conservative, and are in the 25% minority. I think they will
  be@p{--} I don't think they'll be the ones in the business of generating
  coins (they'll be busy selling products or doing the exchange thing).
  @p{»»}

  @p{««}What happens? @p{»»}

  @p{««}Well, the block chain splits. Transactions using coins minted
  before the split will get added to both block chains, and accepted by
  everybody. @p{»»}

  @p{««}Transactions involving "50-coins" (generated after the split) will
  be accepted on the 50-coin chain, rejected on the 25-coin chain. And
  vice-versa. @p{»»}

  @p{««}"50-coiners" would quickly find out that they couldn't get rid of
  their newly minted money because who wants bitcoins that are rejected by
  the biggest money exchangers or merchants? @p{»»}

  @p{««}If the big merchants and money exchangers disagreed, I bet you'd
  see Bitcoin clients that ONLY accepted pre-split coins and did no coin
  generation (since those transactions would be accepted by everybody). If
  it was never resolved, I think the number of Bitcoins at the time of the
  split would become "the number of Bitcoins, period," because most people
  will not want to use money that is accepted some places and not others.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0163}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-10 22:31:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=742.msg8612@s{hash}msg8612
@section 3 {tx}

  @s{quotedtext}

  @p{««}If they are (I didn't see anything preventing them after a quick
  reading of the code), then they trigger the 0.01BTC micro-transaction
  fee. @p{»»}

  @p{««}I'll be doing a lot of experimenting (on the TEST network, of
  course) with refunding transactions over the next few weeks. I think the
  UI issue can be resolved (it should be pretty straightforward to teach
  the UI to recognize refund transactions and show them as "refund from
  BLAH", where BLAH is either a BC address or a label from your address
  book. @p{»»}

  @p{««}I've already implemented a "refundtransaction" api call, but it
  still needs work before it would be ready for standard bitcoin. In
  particular, it shouldn't be possible to create infinite
  'refundtransaction' loops (where you accidentally or purposely
  refundtransaction a refunded transaction, probably triggering another
  refund, etc). @p{»»}

  @p{««}And refunding a transaction should, ideally, use the same "coins"
  (... should have the same ancestor transactions, for anybody who's going
  to get all pedantic on me) as the original transaction, if possible, so
  if that original transaction is exactly as valid as the original
  transaction. Otherwise it might be possible to generate a bad
  transaction, send it somewhere you know it will get refunded immediately
  with different, valid transactions, and so "launder" your bad bitcoins
  for good. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0164}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-11 00:02:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=742.msg8633@s{hash}msg8633
@section 3 {tx}

  @s{quotedtext}

  @p{««}Right, but every TxIn has to have a corresponding TxOut (except for
  GENERATE/coinbase transactions, but those have their own rules). So if
  you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut
  and that'll trigger the fee. TxIns don't contain a value, the value is
  in the corresponding TxOut... @p{»»}

  @s{quotedtext}

  @p{««} But you agree that it wouldn't be OK for a 'refundtransaction' API
  call to make it easy to do that, right?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0165}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-11 16:10:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=788.msg8761@s{hash}msg8761
@section 3 {tx}

  @p{««}Bitcoin's p2p network is subject to various kinds of denial of
  service attacks. @p{»»}

  @p{««}There, I said it. @p{»»}

  @p{««}Do you have constructive suggestions for how to fix it, or are you
  the kind of person who just enjoys breaking things because you can?
  @p{»»}

  @p{««}Ideas that have been bouncing around my head that may or may not
  work: @p{»»}

  @p{««}+ have clients tell each other how many transactions per unit of
  time they're willing to accept. If a client sends you more (within some
  fuzz factor), drop it. Compile in a default that's based on estimated
  number of transactions for a typical user and estimate on the number of
  current users. @p{»»}

  @p{««}+ require some proof-of-work as part of the client-to-client
  connection process (helps prevent 'Sybil' attacks). @p{»»}

  @p{««}This is an active area of research; see, for example: @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0166}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-11 16:40:07 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=788.msg8765@s{hash}msg8765
@section 3 {tx}

  @s{quotedtext}

  @p{««} I was actually thinking of a minute or three of proof-of-work on
  initial connection, not when submitting a transaction, but requiring
  some proof-of-work for every transaction submitted into the network IS a
  very interesting idea! Should be straightforward to implement, too (add
  a nonce and either a full or partial hash to the transaction)... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0167}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-13 03:50:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=792.msg8963@s{hash}msg8963
@section 3 {tx}

  @p{««}Very quick reply, I should be going to sleep: @p{»»}

  @p{««}I think it would be helpful to describe how much anonymity you can
  expect based on what you expect from a potential attacker. @p{»»}

  @p{««}There's a big difference between "I'm worried about somebody
  tracing transactions back to me by looking through the block chain"
  (easy solution: mix up your coins by sending them to and from a
  mybitcoin.com account a couple of times over a couple of days; send them
  in batches over time to be really safe) and "I'm worried about somebody
  tracing the transactions I'm making by watching all of the IP traffic
  coming from my machine (much, much harder to guard against). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0168}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-13 19:28:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg9073@s{hash}msg9073
@section 3 {tx}

  @p{««}I'm proposing one small change to Bitcoin's JSON-RPC api: return a
  transaction ID when Bitcoins are successfully sent. @p{»»}

  @p{««}Why? Because I want to keep a complete audit trail for any coins
  going into or coming out of my application's wallet; I want to keep
  track of the particular transactions in the bitcoin network that
  correspond to actions my application takes. The alternative is to call
  sendtoaddress and then call listtransactions, but that won't work
  properly if two similar transactions (same amount to same address) occur
  at about the same time. @p{»»}

  @p{««}So I propose doing the simplest thing possible: modify the JSON-RPC
  sendtoaddress call so it returns the string 'sent:' followed by the
  256-bit-hexadecimal transactions id. @p{»»}

  @p{««}This could break any applications that look for exactly the string
  'sent' (which is what sendtoaddress does now). The fix would be to
  modify the apps to see if the string began with 'sent'. @p{»»}

  @p{««}Alternatives I thought about but think I don't like: @p{»»}

    @p{(li}@p{(li} make it a new api call so old apps do not break
    (sendtoaddress2 ? yuck) @p{li)} @p{(li} return just the transaction id
    on successful send instead of 'sent:...' @p{li)} @p{(li} return an
    array with more information (maybe @s{code} )
    @p{li)}

  @p{««}Comments/criticisms? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0169}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-13 20:01:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg9086@s{hash}msg9086
@section 3 {tx}

  @p{««}RE: adding a flag: great idea! @p{»»}

  @p{««}If you set the flag, I don't see any reason to prepend 'sent' to
  the transaction ID; better to just return the transaction ID on
  successful send. @p{»»}

  @p{««}Patches: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0170}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-13 20:26:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg9096@s{hash}msg9096
@section 3 {tx}

  @s{quotedtext}

  @p{««}A 'gettransaction tx_id' API call is on my short list. @p{»»}

  @p{««}What do other folks think; should sendtoaddress .... true return
  just the tx_id, and you have to make another API call to get details if
  you need them? @p{brk} Or should it return an Array? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0171}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-14 13:46:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg9194@s{hash}msg9194
@section 3 {tx}

  @s{quotedtext}

  @p{««}You'll never hear me argue with "keep it simple." @p{»»}

  @p{««}Patch for that is trivial: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0172}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-14 14:19:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=796.msg9199@s{hash}msg9199
@section 3 {tx}

  @s{quotedtext}

  @p{««}I see two fundamental problems with using a Bitcoin-like system to
  implement a Universal-Dividend-like system: @p{»»}

  @p{««}1. How does the system identify "individuals" ? If you've got a
  completely automated way of doing that I @p{(bf}really@p{bf)} want to
  know about it! freebitcoins.appspot.com could really use a foolproof
  system for identifying individuals. @p{»»}

  @p{««}2. If everybody gets a dividend, why would anybody bother running a
  block-generating node? What is the incentive for doing the work needed
  to support the system? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0173}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-14 20:11:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=814.msg9252@s{hash}msg9252
@section 3 {tx}

  @p{««}1) Have you been using bitcoin for more than two months? @p{brk}
  Yes, almost 3 months now. @p{»»}

  @p{««}2) Are you currently attempting to generate coins? @p{brk} No
  (well, not on the production network; I am generating blocks on the TEST
  network) @p{»»}

  @p{««}3) If not currently generating, have you attempted in the past? If
  generating, how long have you been generating? @p{brk} Yes, before the
  big slashdot interest influx I was generating. @p{»»}

  @p{««}4) Have you ever succeeded in generating a block? Many blocks?
  @p{brk} Probably around 10 blocks while I was generating. @p{»»}

  @p{««}5) Why or why not do you generate? @p{brk} I'm a big believer in
  the power of division of labor and comparative advantage to make the
  world a better place. I don't have any particular advantage for mining
  bitcoins, and I bet people who _do_ (who have access to lots of cheap
  CPU cycles) will be more efficient at mining than me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0174}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-14 23:57:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg9301@s{hash}msg9301
@section 3 {tx}

  @p{««}Nah, satoshi uses @p{lt}foo@s{gt} to mean "replace this placeholder
  with the actual thingy." @p{»»}

  @p{««}It'd be annoying to constantly strip the @p{lt} and @s{gt} from the
  txid. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0175}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 00:01:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg9302@s{hash}msg9302
@section 3 {tx}

  @p{««}The naming is getting messy: 'txn_id' and 'tx_time' mismatch for no
  good reason. @p{»»}

  @p{««}tx as short for 'transaction' is fine (bitcoin source uses that
  abbreviation all over the place), but the rest of the JSON-RPC API
  doesn't use underscores, so they aught to be txid and txtime. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0176}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 13:08:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=819.msg9431@s{hash}msg9431
@section 3 {tx}

  @p{««}Your proposal seems needlessly complicated. @p{»»}

  @p{««}How about: @p{»»}

  @p{««}The vending machine talks to a "Bitcoin+ Payment Verification
  Systems, Incorporated" server. @p{»»}

  @p{««}The Bitcoin+ Payment Verification System is basically just a
  bitcoin node, with really fast international network connections and a
  little extra code to detect attempted double-spends. If it detects a
  double-spend attempt, it rejects the transaction. Otherwise, it accepts
  the transaction and blasts the transaction into the payment network over
  its really fast, as-low-latency-as-possible connections. @p{»»}

  @p{««}If it later turns out that the transaction actually WAS invalid,
  Bitcoin+ Payment Verification Systems, Incorporated absorbs the cost of
  the fraud. @p{brk} Bitcoin+ Payment Verification Systems, Incorporated,
  of course, charges the vending machine merchant a fee for providing such
  excellent service. They're constantly competing with their arch-rivals,
  "Better Merchant Services, Incorporated" to balance latency, fees, and
  fraud to maximize profit. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0177}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 16:55:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=819.msg9455@s{hash}msg9455
@section 3 {tx}

  @p{««}I'm better at thinking through things using specific examples, so
  bear with me: let's use Mars as the extreme case, and say I'm on Mars
  and want to double-spend some bitcoins. @p{»»}

  @p{««}I talk to my cousin in New York, and send him some coins with the
  "Mars" locality. We agree that we'll use the same coins to buy candy
  bars on January 1, 2040, 10:00:00 UTC, me on Mars and him in New York.
  @p{»»}

  @p{««}So the New York candy machine just rejects my cousin's transaction
  OR makes him wait the 40 minutes for communication between Earth and
  Mars? Wouldn't it be more likely that the New York candy machine just
  accepts the transaction after seeing no double-spends after, oh, I
  dunno, maybe two seconds? @p{»»}

  @p{««}After all, Bitcoin+ Payment Verification Systems, Incorporated
  knows it is highly connected into the majority Bitcoin network with very
  low latency, so it knows that if it blasts a transaction into the
  network and doesn't see a double-spend after two seconds the chances are
  very, very, very good that it will be declared the first spend. @p{»»}

  @p{««}If the New York payment system accepts the transaction every time,
  then the Mars verifier will lose every time. I'm pretty sure the New
  York folks will tell the Mars folks "tough cookies, you should set up
  MarsCoin for low-latency transactions up there." @p{»»}

  @p{««}I don't know much about high speed trading with millisecond
  latency, and, frankly, don't care much about high speed trading with
  millisecond latency. It wouldn't bother me at all if you can't use
  Bitcoin for that (and you have to set up a SpeedyCoin system for doing
  that sort of thing). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0178}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 19:43:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=819.msg9504@s{hash}msg9504
@section 3 {tx}

  @s{quotedtext}

  @p{««}My point is that if there is a lot less cpu power on Mars, then the
  Mars nodes will ALWAYS lose the "create the longest block chain" race.
  So the New York nodes will ALWAYS have the advantage. @p{»»}

  @p{««}And it is nice to say the New York vending machine "shouldn't
  accept a Mars coin within several hours," but, in my experience,
  "shouldn't" doesn't cut it. If the New York candy machine CAN make the
  sale and keep the coins, it WILL. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0179}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 20:39:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=823.msg9524@s{hash}msg9524
@section 3 {tx}

  @p{««}Until there is a better fix... after a very small amount of testing
  this seems to work: @p{»»}

  @s{code}

  @p{««}You'll need to re-download the part of the block chain before the
  bad block@p{--} remove the blkindex.dat and blk0001.dat files. I started
  with @p{(link}knightmb's blockchain@p{link)} snapshot. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0180}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 21:10:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=823.msg9534@s{hash}msg9534
@section 3 {tx}

  @p{««}Looks good to me. @p{»»}

  @p{««}Can you easily hardcode a check for the bad block's hash at startup
  and orphan it and subsequent blocks if they're on the best-block chain?
  @p{brk} It's painful to have to re-download all or most of the chain to
  fix this... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0181}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-15 21:22:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=819.msg9537@s{hash}msg9537
@section 3 {tx}

  @s{quotedtext}

  @p{««}Right, that's my issue with your proposal: what incentive does the
  NY vending machine have to be honest? It can be "dishonest", ignore
  verifiers all-together, and accept more transactions (better for it)
  with less work (also better for it). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0182}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-16 14:11:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=818.msg9742@s{hash}msg9742
@section 3 {tx}

  @p{««}RE: could you make through adroit use of the scripting language:
  you could hide the receiving address, but not the amount. @p{»»}

  @p{««}Bitcoin needs to see TxOut amounts so it can add them up and make
  sure the transaction includes any necessary fees. @p{»»}

  @p{««}And to make sure the transaction is valid, although I suppose it
  could allow invalid-but-not-yet-decrypted transactions into the block
  chain, and just not allow them to be ever spent (it'd be a complicated
  way of deleting BTC). But that makes me extremely nervous@p{--} it seems
  to me it just makes things more complicated and more likely to be
  exploited. @p{»»}

  @p{««}Also, this: "All the network nodes try to decrypt the message with
  each of their public keys" ... won't scale. Busy nodes will have more
  and more public keys over time (as they give out different receiving
  addresses for each purchase transaction), and trying them all whenever
  an encrypted transaction comes over the wire will take an
  ever-increasing amount of time. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0183}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-16 20:30:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=818.msg9819@s{hash}msg9819
@section 3 {tx}

  @p{««}I just want to correct one little thing; excuse me for being
  nit-picky, I'll shut up after this: @p{»»}

  @s{quotedtext}

  @s{quotedtext}

  @p{««}Assuming you have enough memory to store all your public keys in a
  hash table in memory, there is no scaling problem with normal
  transactions. Since the TxOut contains the public key (well, the hash of
  the public key), it is constant time to figure out whether or not the
  TxOut is your public key. You do NOT have to loop through all your
  public keys to see which one matches. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0184}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-08-30 22:23:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=231.msg11709@s{hash}msg11709
@section 3 {tx}

  @s{quotedtext}

  @p{««}Neither of those are feasible@p{--} both App Engine and Javascript
  don't allow arbitrary socket connections, and a full bitcoin client
  needs to maintain a persistent connection to at least one other bitcoin
  client to get transaction messages. @p{»»}

  @p{««}"Background servers capable of running for longer than 30s" is a
  feature on Google's @p{(link}roadmap@p{link)}, so maybe a 100% App
  Engine bitcoin client will be possible in the future. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0185}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-01 18:33:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg11870@s{hash}msg11870
@section 3 {tx}

  @s{quotedtext}

  @p{««}RE: JSON-RPC error / HTTP status codes: I'm about to submit a patch
  to Satoshi so bitcoin better follows the JSON standards. I'll create a
  new thread describing the changes. @p{»»}

  @p{««}RE: binding to any/all IPs: DANGER! Make sure you have good
  firewall rules for port 8332 or you are likely to find yourself with an
  empty wallet! Bitcoin is using HTTP BASIC authentication, so anybody who
  can eavesdrop on the connection between your JSON-RPC client and the
  bitcoin server can see the password (it is NOT encrypted). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0186}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-01 19:35:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=611.msg11876@s{hash}msg11876
@section 3 {tx}

  @s{quotedtext}

  @p{««}I wouldn't bother@p{--} HTTP Digest auth is vulnerable to
  man-in-the-middle attacks, it'd be a lot of work for a probably false
  sense of security. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0187}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-01 20:28:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=969.msg11884@s{hash}msg11884
@section 3 {tx}

  @p{««}I just submitted a patch to Satoshi to make bitcoin follow the
  @p{(link}JSON RPC over HTTP spec,@p{link)} and to use the standardized
  error codes from the JSON-RPC 1.1/2.0 specs. @p{»»}

  @p{««}If you talk directly to bitcoin via JSON-RPC calls, you might need
  to change your code to recognize the new HTTP status codes and the new
  format for the 'error' member of the JSON response. For example: @p{»»}

  @p{««}BEFORE, send @s{code} , get response: @s{code} @p{»»}

  @p{««} I also removed the broken 'Batch' support, to simplify the code. I
  had JSON-RPC-2.0 batch support working properly, but backed those
  changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to
  support right now (none of the JSON-RPC glue libraries support it yet,
  and the spec is still changing a bit). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0188}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-01 22:06:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=978.msg11889@s{hash}msg11889
@section 3 {tx}

  @s{quotedtext}

  @p{««}It isn't trivial to obtain the secret unless you patch the code to
  bind to interfaces other than loopback.... @p{»»}

  @p{««}SSL connections are The Right Answer. @p{»»}

  @p{««}If I had any OpenSSL programming experience I'd volunteer to
  implement it. Anybody willing and able to teach bitcoin to speak https?
  @p{»»}

  @p{««}And for extra credit, support SSL client certificates for
  authentication either instead of or in addition to HTTP-Basic... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0189}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-03 23:41:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=978.msg12002@s{hash}msg12002
@section 3 {tx}

  @p{««}Nobody volunteered, but the boost ssl LOOKS like it will make it
  easy... so I've started playing around with it. @p{»»}

  @p{««}After much wrestling with the (sucky) OpenSSL and boost::asio::ssl
  docs, I've got a standalone, dumb, Satoshi-style-c++ https server
  running (code below). @p{»»}

  @p{««}Are there any real OpenSSL experts here who can review the code and
  answer questions like: @p{»»}

  @p{««} + I understand the temp Diffie-Hellman file contains large prime
  numbers used to do public key exchange. Everything works just fine if I
  leave out the call to context.use_tmp_dh_file; what are the security
  implications? Will it matter for what we'll be doing (securing the
  JSON-RPC channel from eavesdropping/man-in-the-middle attacks)? @p{»»}

  @p{««} + I'm following the advice from @p{(link}here@p{link)}, excluding
  old, low-security ciphers using: @p{»»}

    @s{code}

    @p{(li} Am I correct in assuming that any sane JSON-RPC/HTTP/HTTPS
    library will support the higher-strength ciphers? Or does Java on a PC
    do something braindead and support only DES-MD5? (and yeah, I'll make
    this overridable via a config file param, but I want to get the
    defaults right) @p{li)}

  @p{««}+ Oh, and a C++ expert question: what magic incantation will turn
  the boost::asio::ssl::stream into an iostream that understands
  @p{lt}@p{lt} and @s{gt}@s{gt} ? @p{»»}

  @p{««}And thumbnail sketch of how I imagine this working with bitcoin:
  @p{»»}

  @p{««}+ config file setting to turn on ssl/tls rpc ( maybe rpcssl=true
  ... or should it be rpctls=true ? ) @p{»»}

    @p{(li}@p{(li} if turned on, only ssl connections accepted on the
    rpcport @p{li)} @p{(li} if turned on, bitcoin binds rpcport to all
    addresses (not just 127.0.0.1) @p{li)}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0190}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-06 16:48:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=978.msg12114@s{hash}msg12114
@section 3 {tx}

  @p{««}Bear with me, this is a brain dump to try to organize my thoughts
  on securing the client @p{lt}@p{--}@s{gt} bitcoin JSON-RPC connection:
  @p{»»}

  @p{««}First: @p{(bf}Preventing man-in-the-middle attacks@p{bf)}: @p{»»}

  @p{««}HTTPS only prevents man-in-the-middle attacks if it is implemented
  properly by the client. Example attack scenario against a lazy client:
  @p{»»}

  @p{««}@p{(li}Client connects to "@s{(link)}"@p{li)}

  @p{««}@p{(li}Attacker intercepts connection (e.g. via a DNS poisoning
  attack), and connects to the client using it's certificate.@p{li)}

  @p{««}@p{(li}Client gets certificate and @p{(it}doesn't bother to verify
  that the connection certificate is for bitcoinservice.org@p{it)}.
  Completes SSL handshake.@p{li)}

  @p{««}@p{(li}Client then continues conversation by sending JSON-RPC
  request containing unencrypted rpcuser/rpcpassword.@p{li)}

  @p{««}@p{(li}Attacker now has rpcuser/rpcpassword and can mount a
   man-in-the-middle attack against the bitcoin server.@p{li)} @p{brk} The
   "correct" way to prevent this is for clients to properly authenticate
   the server's certificate, but I don't think that's practical@p{--} the
   default behavior for most url-opening libraries (used by the various
   JSON-RPC libraries) is to @p{(bf}NOT@p{bf)} validate server
   certificates. You have to write extra code to install certificate
   authorities and/or write callbacks to examine the certificate and
   determine whether or not it is the certificate you expect. @p{»»}

  @p{««}I think a more practical way for the client to prevent a
  man-in-the-middle attack is for the client to hard-code the bitcoin
  server's IP address and avoid any DNS lookups@p{--} connect to
  @s{(link)} (if bitcoinservice.org is at IP 111.11.11.111). It is much,
  much harder to successfully IP spoof a TCP connection than it is to
  successfully poison a DNS cache. @p{»»}

  @p{««}"Security in depth" is a good idea, and I've thought about layering
  other mechanisms for making the client-@s{gt}server connection secure,
  but I think we'd just be duplicating SSL functionality. For example, I
  can imagine encrypting the whole JSON-RPC request string with a
  pre-shared key known to the clients and the server, but that's just a
  lame version of the strong encryption you get from SSL if the client is
  properly validating server certificates. I think the security-in-depth
  will come from having the server authenticate clients, which brings me
  to: @p{»»}

  @p{««}Second: @p{(bf}Authenticating clients@p{bf)}: @p{»»}

  @p{««}The whole point of implementing HTTPS on the bitcoin JSON-RPC port
  is to allow connections from IP addresses other than 127.0.0.1. But the
  "security-in-depth" idea means we almost certainly don't want to allow
  just @p{(it}anybody@p{it)} to connect and start sending bitcoins from
  our wallet. Even if an attacker manages to steal the
  rcpuser/rpcpassword, we'd like to prevent them from emptying out our
  wallet if they try to connect from an unauthorized machine (if they
  @p{(bf}can@p{bf)} connect from an authorized machine you're already
  screwed). @p{»»}

  @p{««}Again, the "correct" way to authenticate clients is to do the
  public-key-infrastructure thing (... create a master bitcoin certificate
  you'll use as your certificate authority, then create public/private
  keys and certificates signed by that authority and require the clients
  and server to accept only connections properly signed with the right
  keys...). And I think bitcoin should definitely support validating
  client certificates (that's just a couple of lines of OpenSSL library
  calls). @p{»»}

  @p{««}But again, I'm worried that some people deploying bitcoin either
  won't bother or will be using languages/libraries/systems that make it
  difficult or impossible to send a client certificate when connecting.
  @p{»»}

  @p{««}Hard-coding the IP addresses of clients that are allowed to connect
  via HTTPS (maybe allowing wild-carding of IP ranges) is a much
  easier-to-setup, almost-as-secure, way to authenticate clients. @p{»»}

  @p{««}So, to summarize my current thoughts on all this: @p{»»}

  @p{««}@p{(bf}Recommendation for clients will be to:@p{bf)} @p{»»}

  @p{««}@p{(li}Connect to the bitcoin JSON-RPC port via IP address
  and/or:@p{li)}

  @p{««}@p{(li}Properly validate the bicoin server certificate@p{li)}
   @p{brk} @p{(bf}The bitcoin JSON-RPC-https server will require:@p{bf)}
   @p{»»}

  @p{««}@p{(li}Server private/public keys (generated using openssl,
  filename/path specified in bitcoin.conf file)@p{li)}

  @p{««}@p{(li}IP addresses (or ranges) of clients that are allowed to
  connect in the bitcoin.conf file@p{li)}

  @p{««}@p{(li}(optional)Certificate authority file used to validate
   clients (they must connect using a certificate signed by that
   authority)@p{li)} @p{brk} What do y'all think@p{--} sound reasonable?
   @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0191}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-06 19:18:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=969.msg12125@s{hash}msg12125
@section 3 {tx}

  @p{««}Speak now about this change or forever hold your peace... Satoshi
  will be including this functionality in the next version of Bitcoin
  (0.3.12). @p{»»}

  @p{««}If you use the JSON-RPC api, you should check your
  error-condition-handling code; again, the changes are that the error
  member will be an Object (with 'code' and 'message' fields) instead of a
  String, and the HTTP status code may be 404 instead of 500 for
  method-not-found. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0192}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-08 13:27:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=978.msg12226@s{hash}msg12226
@section 3 {tx}

  @p{««}Unlike a public HTTPS web server, which accepts connections from
  anybody, the bitcoin HTTPS JSON-RPC server will only accept connections
  from trusted clients, and you'll almost certainly be your own root
  certificate authority@p{--} there is no reason to pay for a Verisign
  certificate, you should generate your own and deploy it with the code
  that is talking JSON-RPC to your server. @p{»»}

  @p{««}Or, in other words, since you'll control both ends of the
  conversation (as opposed to a web server, where you typically control
  EITHER the server OR the web browser) you can make it completely secure.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0193}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-13 12:38:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1026.msg12557@s{hash}msg12557
@section 3 {tx}

  @p{««}This bitcoind address validator is a subclass of the Django
  forms.CharField class, but could easily be adapted to other frameworks
  or to be standalone code. @p{»»}

  @p{««}It does a "deep" validation, checking that the checksum built into
  every bitcoin address matches the address. It needs the PyCrypto library
  for the SHA256 function. @p{»»}

  @p{««}I hereby release this code into the public domain, do with it what
  you will. And please let me know if you find any bugs in it. @p{»»}

  @s{code}

  @p{««}@p{(bf}October 20:@p{bf)} Fixed bug with bitcoin addresses with
  leading-1's.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0194}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-14 19:35:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1032.msg12792@s{hash}msg12792
@section 3 {tx}

  @s{quotedtext}

  @p{««}... but a payer typically has only the bitcoin address, and not the
  payee's full public key. There'd have to be some way to get the full
  public key for a bitcoin address. @p{»»}

  @p{««}I like the idea of being able to send encrypted messages to
  "whoever has bitcoin address BLAH", but I'm not sure that functionality
  should be piggybacked on the "send BLAH X.YZ bitcoins". @p{»»}

  @p{««}If they were implemented under the covers as separate functions,
  then a "Send a message along with payment" could easily be implemented
  as: @p{»»}

    @p{(li}1. Send BLAH X.YZ bitcoins, and note the transaction ID.
    @p{li)}

    @p{(li}2. Send BLAH an encrypted message:
    "txid:{transaction_id}:Please send the sixteen My Little Pony DVDs
    to..." @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0195}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-15 15:16:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=978.msg12880@s{hash}msg12880
@section 3 {tx}

  @p{««}Implementation was easy, once I figure out how
  boost::asio::ssl::stream worked... @p{»»}

  @p{««}Anyway, I've created a git branch for anybody who's willing to help
  test: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Documentation for what I done did: @p{»»}

  @p{««}Communicating with the Bitcoin JSON-RPC interface over SSL (https)
  @p{»»}

  @p{««}By default, bitcoin allows JSON-RPC commands to be sent to @p{brk}
  @s{(link)}, and accepts connections only from the local @p{brk} host.
  @p{»»}

  @p{««}It can be configured to allow https connections from other hosts;
  @p{brk} three things must be setup for this to work properly: @p{»»}

  @p{««}1. You must setup a server certificate and private key. A
  self-signed @p{brk} certificate will work, you don't need a certificate
  signed by Verisign @p{brk} or another certificate authority. @p{»»}

  @p{««}By default, bitcoin looks for the server's private key file in a
  @p{brk} "server.pem" in the bitcoin data directory (e.g.
  ~/.bitcoin/server.pem @p{brk} on unix), and the server certificate file
  in "server.cert". To @p{brk} generate them using the openssl
  command-line program, run: @s{code} @p{»»}

  @p{««}You should NOT enter a passphrase. @p{»»}

  @p{««}2. Specify the IP addresses of clients that are allowed to connect
  using @p{brk} "rpcallowip" configuration file options. @p{»»}

  @p{««}Edit the bitcoin.conf file (in the bitcoin data directory), and add
  a @p{brk} line for each IP address allowed to connect: @p{»»}

    @s{code}

  You may also allow connections from any IP address in a subnet using *:
  @p{»»}

    @s{code}

  You can also specify 'rpcallowip=*' to allow all IP addresses. @p{»»}

  @p{««}Connections from the local host (127.0.0.1) are always allowed.
  @p{»»}

  @p{««}3. You must tell bitcoin to use ssl using the "rpcssl"
  configuration file option. @p{»»}

  @p{««}Edit the bitcoin.conf file, and add: @p{»»}

    @s{code}

  @p{««}Restart bitcoin or bitcoind to make these changes take effect. You
  @p{brk} can test bitcoin's ssl functionality using the openssl s_client
  command: @p{»»}

    @s{code}

  @p{««}The connection should be successful and you should see the server's
  @p{brk} certificate details. If you press return twice, you should get a
  '@s{code}' response. @p{»»}

  @p{««} Client setup @p{»»}

  @p{««}Once the server is accepting https connections, to be secure you
  should @p{brk} make sure the client is actually connecting to the
  bitcoin server and @p{brk} not an attacker trying to hijack the
  connection. @p{»»}

  @p{««}If you can, you should copy the server.cert certificate chain file
  to @p{brk} the client machine and use it to validate the OpenSSL
  connection. @p{brk} For example, in php you would call
  stream_context_create() with @p{brk} the 'verify_peer' and 'ca_file'
  options and then call @p{brk} stream_context_set_default(). @p{»»}

  @p{««}If you can't validate using the server certificate, you should
  connect @p{brk} to the server using its IP address instead of its host
  name. @p{»»}

  @p{««} All HTTPS-JSON-RPC-related bitcoin.conf options: @p{»»}

    @p{(li} rpcport : default: 8332 Listen for connections on this port
    @p{li)} @p{(li} rpcuser : user for HTTP BASIC authentication @p{li)}
    @p{(li} rpcpassword : password for HTTP BASIC authentication @p{li)}
    @p{(li} rpcssl : Not set by default, if set bitcoin will only accept
    SSL connections @p{li)} @p{(li} rpcallowip : Allow a client at this IP
    address to connect (may be specified multiple times) @p{li)} @p{(li}
    rpcsslciphers: default "@s{code}" (see the openSSL documentation for
    syntax) @p{li)} @p{(li} rpcsslcertificatechainfile : default
    "server.cert" @p{li)} @p{(li} rpcsslprivatekeyfile : default
    "server.pem" @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0196}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-15 17:20:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1043.msg12895@s{hash}msg12895
@section 3 {tx}

  @p{««}Picking up from the original thread... @p{»»}

  @p{««}Bitcoin-related sites that have self-signed or CACert certificates
  (like mybitcoin.com) look unprofessional and un-trustworthy to clueless
  non-techies. @p{»»}

  @p{««}I know, I know, a Verisign-certified certificate isn't
  @p{(it}really@p{it)} any guarantee of security, but that doesn't
  matter@p{--} if you want ordinary users to start trusting your website,
  get a certificate that doesn't popup any scary-looking security
  warnings. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0197}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-15 20:24:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1045.msg12908@s{hash}msg12908
@section 3 {tx}

  @p{««}I added some information on the "OP_RETURN" bug that triggered the
  0.3.5 release (and that we weren't talking about because we didn't want
  it to get exploited on the main network before people had a chance to
  upgrade). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0198}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-16 02:15:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1042.msg12945@s{hash}msg12945
@section 3 {tx}

  @p{««}What is the use case for this? @p{»»}

  @p{««}Is it just to make it easier to send anonymous donations by typing
  in Pay To: "redcross.org" instead of copying&amp;pasting a bitcoin
  address? @p{»»}

  @p{««}If something like that were implemented, seems like it would just
  invite the same kind of abuse we see with
  misspelled-domain-squatters@p{--} setup a domain record for
  "redcros.org" pointing to a non-Red Cross bitcoin address and take
  advantage of people's fat-fingered misspellings. One big advantage of
  bitcoin addresses is that they have a built-in checksum, so if you
  misspell them (or screw up the copy&amp;paste) your attempted
  transaction will be immediately rejected. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0199}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-17 18:16:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1056.msg13070@s{hash}msg13070
@section 3 {tx}

  @p{««}The @p{(link}bitoin URI thread@p{link)} has died down, but
  bitcoinmarket and MtGox's spiffy "click to pay" features prompted me to
  think some more about payment links on web pages. @p{»»}

  @p{««}The problem with the MtGox/Bitcoinmarket solutions is that they
  still require you to copy&amp;paste an address if you want to pay
  directly from the bitcoin client running on your machine. My
  computer-phobic relatives just won't be able to do that (I can hear them
  saying "...BUT I DON'T HAVE A COPY BUTTON..."). @p{»»}

  @p{««}But a bitcoin: URI has problems, too: @p{»»}

    @p{(li} 1. It is hard to implement@p{--} every browser has a different
    way of registering protocol handlers. @p{li)} @p{(li} 2. If you don't
    have the protocol handler installed, clicking on the link doesn't give
    you any help on what to do to make it work. (try it
    @p{(link}here@p{link)}) @p{li)} @p{(li} 3. Looks like some software
    (like this forum) don't like bitcoin URIs: @p{(link}Donate to the
    Faucet@p{link)} (that URI is @p{(link}bitcoin:@s{btcaddress},@p{link)}
    the forum software is truncating it and adding @s{(link)}). @p{li)}

  @p{««}Maybe a bitcoin payment request MIME type would work better; you
  click on a link and the web server returns a little file of type
  "application/bitcoin-payment-request". @p{(link}Like this.@p{link)} Or
  @p{(link}the links on this page@p{link)}. @p{»»}

  @p{««}If you're running Firefox, you get this dialog box if it doesn't
  know about application/bitcoin-payment-requests: @p{»»}

  @s{image}

  @p{««}On PCs, an app can add stuff to the registry to associate itself
  with a mime type (anybody know if browsers other than IE pay attention
  to those registry settings?). @p{»»}

  @p{««}Macs are similar (although I don't know the details; gotta set the
  mime type in the App's Info.plist, I believe...). Anybody know about
  Linux? @p{»»}

  @p{««}Teaching the Bitcoin application to read the
  bitcoin-payment-request file would be easy, and it shouldn't be terribly
  hard to get it to ask an already-running Bitcoin to popup a "Send
  Payment To..." dialog box with fields filled in (OR get it to start
  itself running and then popup the dialog box). @p{»»}

  @p{««}So: whaddya think? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0200}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-19 15:19:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1063.msg13198@s{hash}msg13198
@section 3 {tx}

  @p{««}I agree with nelisky@p{--} not a bug. Here's what the unix cat
  command has to say about "": @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0201}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-20 00:12:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133.msg13230@s{hash}msg13230
@section 3 {tx}

  @s{quotedtext}

  @p{««} @p{(link}bitcointools@p{link)} can tell you all transactions to a
  particular bitcoin address: @p{»»}

  @s{code}

  @p{««} ... etc... @p{»»}

  @p{««} Feed that to a little script that just looks for value:
  (something) pubkey: 1HZNsUq and totals up the (somethings) and you can
  figure it out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0202}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-20 12:41:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1056.msg13445@s{hash}msg13445
@section 3 {tx}

  @p{««}RE: hippich XML/JSON: @p{brk} XML ain't gonna happen, and I think
  JSON is overkill for this. Using the same format as the bitcoin.conf
  file is the right answer, I think (easy to implement, human-readable,
  comments allowed in the file, easy to extend as necessary). That's what
  I mocked up at skypaint.com. @p{»»}

  @p{««}RE: nimnul @s{(link)}:.../ @p{brk} If you've never installed
  bitcoin, or bitcoin isn't running already, you get an unhelpful error
  message. One advantage of a "payment request file" is many users will
  understand that you need something called "Bitcoin" to open a "Bitcoin
  Payment Request" file. @p{»»}

  @p{««}RE: mizerydearia Linux support: @p{brk} In my research I briefly an
  across a reference to a KDE startup file to associate mime types with
  applications, so I @p{(it}think@p{it)} it would work nicely
  cross-platform if you've already installed bitcoin. (UPDATE:
  cross-desktop @p{(link}spec here@p{link)}) @p{»»}

  @p{««}RE: nimnul clipboard monitoring: @p{brk} Seems to me that's a
  feature for geeks, because only geeks would happen to know that if you
  highlight a bitcoin address when bitcoin was running you could
  automatically launch bitcoin. And there's no way that would be turned on
  by default. And it also seems to me clipboard monitoring is perfect for
  a standalone, general-purpose utility ("if selection matches any of
  THESE regepxs, launch THAT applications with arguments "beginpayment
  %{address} %{amount}" ... ). @p{»»}

  @p{««}RE: mizerydearia portable devices: @p{brk} I've never programmed
  for Android or iPhone; anybody know how they handle non-standard MIME
  types? Can apps register themselves as content handlers? @p{»»}

  @p{««}Thinking about actually implementing this, the hard part is getting
  a running (or just launched) Bitcoin's attention in a cross-platform
  way. Using the existing command-line control (which uses JSON-RPC under
  the covers) would be the most straightforward, but that requires that
  you set a rpcuser/rpcpassword in the bitcoin.conf file AND run bitcoind
  or bitcoin -server. Yuck. @p{»»}

  @p{««}I suppose, as a special case, payment request JSON-RPC calls could
  be allowed with no rpcpassword, and -server could be made the default.
  Makes me a little nervous, though. @p{»»}

  @p{««}Running bitcoin /path/to/browser/cache/with/payment_request_file
   (which is what the web browsers will do) should: @p{brk} IF bitcoin
   isn't running: launch it, and @p{(bf}wait@p{bf)} until it is ready to
   receive payment request messages @p{brk} Send running bitcoin
   (...somehow...) "Hey, we got a payment request here for you to deal
   with" messgae. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0203}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-21 13:31:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=984.msg13577@s{hash}msg13577
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, both IP and port are encoded in the @s{hash}bitcoin IRC usernames
  (see the EncodeAddress/DecodeAddress routines in irc.cpp). @p{»»}

  @p{««}(so mizerydearia: no need to do what you done did...)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0204}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-21 16:42:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1264.msg13609@s{hash}msg13609
@section 3 {tx}

  @p{««}Hmm... I guess I was too slow: @p{»»}

    @p{(li}"PAYMENT TIMED OUT! We didn't receive a payment from you. Try
    again." @p{li)}

  @p{««}I copied the generated BTC address, but forgot the amount by the
  time Bitcoin launched, so sent you 1.11 (eleven is my favorite number)
  bitcoins. @p{»»}

  @p{««}Now I didn't get whatever it was I paid for. @p{»»}

  @p{««}Definitely cool, but also definitely clunky. Where this needs to
  go, in my humble opinion: @p{»»}

    @p{(li} 1. MyBitcoin should get rid of the CAPTCHA for most users (do
    the Google thing, and only show the CAPTCHA if it detects potential
    abuse) (oh, you didn't know Google search does that? Yup, they do, if
    you do enough weird-looking searches quickly enough you'll get a
    CAPTCHA...) @p{li)}

    @p{(li} 2. Bitcoin needs a 'refundtransaction' feature, to get rid of
    the scary "Do not ever reuse a temporary payment address or your
    Bitcoins may get lost" warning. Sending to an old address should just
    do an immediate refund. @p{li)}

    @p{(li} 3. I want to be able to put the payment address into MyBitcoin
    and see the status of my payment. @p{li)}

    @p{(li} 4. Gotta get rid of the "memorize the amount and then copy and
    paste to Bitcoin" (need a bitcoin-payment-request MIME type, in my
    humble opinion). @p{li)}

    @p{(li} 5. Gotta improve Bitcoin startup speed; at the very least,
    make the UI come up quickly while it re-verifies the block chain (I
    think that's what it is doing...). @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0205}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-21 17:12:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1264.msg13616@s{hash}msg13616
@section 3 {tx}

  @s{quotedtext}

  @p{««} I shoulda been more clear: I've now got a 1.11 payment to (some
  random address) in Bitcoin; I want to take that (some random address)
  and give it to MyBitcoin (or you, the merchant) and see what's up with
  that payment. Ideally, it would pick up the payment process as if the
  PAYMENT TIMED OUT never happened. @p{»»}

  @p{««}And MadHatter: keep the change. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0206}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-21 17:41:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1263.msg13623@s{hash}msg13623
@section 3 {tx}

  @p{««}I believe that the statement: "bitcoin is new kind of money" passes
  the @p{(link}duck test@p{link)}. @p{»»}

  @p{««}Bitcoins function as money (they're a unit of account, a medium of
  exchange, and a store of value), and if PayPal started allowing Bitcoin
  transactions tomorrow I'm certain they'd treat them as Just Another
  Currency. @p{»»}

  @p{««}If you like, call it a commodity, but I think all you'll accomplish
  is confusing potential users who might think they'll end up getting
  pork-bellies delivered to their porch if they don't get rid of their
  bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0207}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-22 13:47:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1019.msg13696@s{hash}msg13696
@section 3 {tx}

  @p{««}I think a big publicity splash should wait until Bitcoin 1.0.
  Bitcoin still has way too many rough edges for ordinary folk to use
  (watch them run away screaming as you try to explain that it is NORMAL
  for it to take half an hour to download the block chain the first time
  you start Bitcoin....). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0208}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-24 12:16:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1276.msg13939@s{hash}msg13939
@section 3 {tx}

  @p{««}"Mainstream" users want a more-selection, less expensive, just as
  fast variant of iTunes. Frankly, I don't think an illegal filesharing
  site can scratch that itch and stay in business for long (I'm curious to
  see how long mulve.com lasts). @p{»»}

  @p{««}If it could, I think a bitcoin-revenue-sharing business model would
  work well@p{--} "We'll give you 50% of the revenue from any downloads of
  stuff you upload" (and "we" charge x-bitcoins-per-download). @p{»»}

  @p{««}But I think even if such a service existed there would still be a
  bunch of people who refuse to pay a bit-penny for downloads. But I agree
  with lfm@p{--} I think many of them would be willing to pay
  @p{(it}indirectly@p{it)} for downloads; you just have to tell them that
  they're paying for "X gigbytes of premium bandwidth" or something...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0209}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-24 12:29:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=842.msg13941@s{hash}msg13941
@section 3 {tx}

  @p{««}With just a web browser you can open an account at bitcoinmarket,
  mybitcoin, or mtgox and send/receive bitcoins. @p{»»}

  @p{««}The only thing you're not able to do is try to generate bitcoins,
  but you said you don't have a computer at home and it sounds like your
  employer wouldn't be very... uhh, supportive... of you using their
  electricity to try to generate bitcoins. @p{»»}

  @p{««}If they would be supportive (long ago I wrote software at a
  hardware company where they actually LOOKED FOR CPU-intensive
  applications to run during system burn-in, so they'd ship fewer
  dead-shortly-after-arrival units) then they'd probably be happy to open
  up outbound connections to port 8333. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0210}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-24 13:28:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1267.msg13944@s{hash}msg13944
@section 3 {tx}

  @s{quotedtext}

  @p{««} For extra credit, give an Object as the return value: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0211}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-24 19:02:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1270.msg13959@s{hash}msg13959
@section 3 {tx}

  @s{quotedtext}

  @p{««}An irresponsible central bank. @p{»»}

  @p{««}I think that scenario is unlikely for dollars, because the Federal
  Reserve central bankers already have a lot of dollar-denominated wealth,
  so have a strong incentive to avoid hyperinflation. @p{»»}

  @p{««}Compare that to the Zimbabwe central banker, who is basically under
  the thumb of a dictator who most likely holds his wealth in foreign
  currencies. Their incentive is to squeeze as much wealth out of the
  economy before it collapses and they're deposed in the next coup. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0212}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-27 15:14:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=665.msg14254@s{hash}msg14254
@section 3 {tx}

  @p{««}The "label" mechanism (setlabel / getreceivedbylabel) is supposed
  to meet this need, but only solves part of the problem. @p{»»}

  @p{««}If the API was extended as I describe below, would it solve the
  same problems as having multiple wallets? @p{»»}

  @p{««}Proposal: @p{»»}

  @p{««}new send method: send TO a given bitcoin address specifically FROM
  the bitcoins sent to @p{lt}label@s{gt} @p{»»}

    @p{(li}(change generated would be automatically tagged with @p{lt}
    label@s{gt}) @p{li)}

    @p{(li} add optional (label) param to getbalance. @p{li)} 
    
    @p{(li} new method: listsentbylabel (returns array of @s{code}) @p{li)}

  @p{««}Each customer "account" would be a bitcoin @p{lt}label@s{gt}.
  Account handling would look like: @p{»»}

  @p{««}Create account / create new address for account: @p{»»}

    @p{(li}getnewaddress (account_id_label) ... tell user "fund your
    account by sending coins to {the address returned}" @p{li)}

  @p{««}Customer withdraws/spends: @p{»»}

    @p{(li}sendfrom (account_id_label) (address) (amount) (FAILS if
    balance for that account too low) @p{li)}

  @p{««}Show customer their balance: @p{»»}

    @p{(li}getbalance (account_id_label) @p{li)}

  @p{««}Show customer their transactions in/out @p{»»}

    @p{(li}listreceivedbylabel (account_id_label) @p{li)}

    @p{(li}listsentbylabel (account_id_label) @p{li)}

  @p{««}Seems to me this would be a much better direction to go in, rather
  than having separate wallet.dat files for each customer. At the very
  least, backing up thousands of customer's wallet files would be
  inefficient and error-prone, and constantly switching between them would
  also be incredibly inefficient. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0213}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-27 17:10:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=665.msg14264@s{hash}msg14264
@section 3 {tx}

  @p{««}Separate "accounts" (addresses with labels) to accumulate Jackpots
  is the right idea. Users buy tickets, bitcoins are moved to the
  appropriate Jackpot account. When a Jackpot is won, transactions flow
  out of its account back to whoever won. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0214}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-27 17:57:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=724.msg14266@s{hash}msg14266
@section 3 {tx}

  @p{««}I've been working on a "monitoraddress" / "monitorblocks" patch, so
  bitcoind will POST transaction/block information to an arbitrary URL.
  @p{»»}

  @p{««}And it seems to me "getblock" should be split into
  "getblockbycount", "getblockbyhash" and "gettransaction". I also have
  some suggestions for making the naming more consistent: @p{»»}

  @p{««}I'd suggest getblockby* return: @p{»»}

  @s{code}

  @p{««} Reasoning: @p{»»}

    @p{(li}blockcount instead of 'height' or 'depth' because getinfo
    returns "blockcount" @p{li)}

    @p{(li}getblockbyhash might return a block not on the "best" chain;
    return blockcount=-1 in that case? @p{li)}

    @p{(li}version instead of 'ver' because abbrvs shd b avoided (thy cn b
    hrd to rd/rmbr) @p{li)}

    @p{(li}only return transaction hashes; if you need more transaction
    details, call gettransaction. @p{li)}

    @p{(li}No n_tx (or n_anything) because it is implicit in length of
    returned array @p{li)}

  @p{««}(stuff I'm not sure about: what is 'bits' in the implemented
  getblock? Is that difficulty? Does anybody really need all the detailed
  merkle tree info?) @p{»»}

  @p{««}I'd suggest gettransaction return: @p{»»}

  @s{code}

  @p{««} Reasoning: @p{»»}

    @p{(li}Returning the CScript string seems like it is both too much
    detail AND not very useful (I want the bitcoin addresses, NOT OP_DUP
    0xblahblahblah ...) @p{li)}

    @p{(li}"from" is just a list of pointers to previous transaction "to"s
    @p{li)}

    @p{(li}confirmations is duplicate info (you could getblockbyhash and
    then look at its blockcount), but is so useful I think it belongs
    here. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0215}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-27 19:40:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=724.msg14297@s{hash}msg14297
@section 3 {tx}

  @p{««}blkindex.dat contains all the transactions, in records that look
  like: @p{»»}

    @p{(li}key: "tx" + HASH_OF_TRANSACTION @p{li)}

    @p{(li}value: serialized CTxIndex @p{li)}

  @p{««}The CTxIndex points to a record in one of the blk000n.dat files.
  @p{»»}

  @p{««}That does bring up an interesting point, though: if lightweight
  clients are implemented, they wouldn't be able to support an arbitrary
  'gettransaction'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0216}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-30 13:57:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg14699@s{hash}msg14699
@section 3 {tx}

  @p{««}@p{(link}This patch@p{link)} adds the following JSON-RPC commands
  to bitcoin/bitcoind: @p{»»}

    @p{(li}@p{(bf}monitoraddress @p{lt}bitcoinaddress@s{gt}
  @p{lt}url@s{gt} (monitor=true)@p{bf)} @p{li)} When coins are sent to
  @p{lt}bitcoinaddress@s{gt} POST JSON transaction info to
  @p{lt}url@s{gt}. @p{brk} If @p{lt}bitcoinaddress@s{gt} is 'allwallet'
  then monitor coins sent to all of your addresses. @p{brk} Pass false as
  third param to stop monitoring.@p{li)}

    @p{(li}@p{(bf}monitorblocks @p{lt}url@s{gt} (monitor=true)
  (startblockcount=0)@p{bf)} @p{li)} POST block information to
  @p{lt}url@s{gt} as blocks are added to the block chain. @p{brk}
  (monitor) true will start monitoring, false will stop. @p{brk} Pass
  (startblockcount) to start monitoring at/after block with given
  blockcount.@p{li)}

    @p{(li}@p{(bf}listmonitored@p{bf)} @p{li)} Returns list describing
  where blocks and transactions are being POSTed.@p{li)}

    @p{(li}@s{code} Returns
  details of the block with @p{lt}hash@s{gt} (hexadecimal) or
  @p{lt}number@s{gt}.@p{li)}

    @p{(li}@p{(bf}gettransaction @p{lt}hash@s{gt}@p{bf)} @p{li)} Returns
  details of transaction with @p{lt}hash@s{gt} (hexadecimal).@p{li)} This
  patch also modifies the "sendtoaddress" function so it returns the
  transaction ID on a successful send (instead of the string "sent").
  @p{»»}

    @p{(bf}If you use the monitor* functionality@p{bf)} to POST
    information be sure to think through the security of your application.
    For example, if you use monitoraddress to get notified of customer
    payments you should think about whether or not a customer could fake a
    payment by POSTing bogus information to your web server. @p{»»}

  @p{««}Full source code is at: @s{(link)} @p{brk} As always, bug reports,
  suggestions for improvement and feedback is welcome. @p{»»}

  @p{hrule}

  @p{««}@p{(it}Updated monitoraddress/getblock commands as discussed
  below@p{it)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0217}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-30 16:34:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg14713@s{hash}msg14713
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good Idea, and that aught to be easy. @p{»»}

  @p{««}I'm thinking it should be: @p{»»}

    @p{(li}monitoraddress allwallet @p{lt}url@s{gt} @p{li)}

  @p{««}... instead of a separate monitor command. @p{»»}

  @p{««}Come to think of it, maybe I should combine the getblockby*
  routines into one; there's no chance of mistaking a 64-character hex
  block hash for a 5-digit (or, in many years, a six or seven or ten
  digit) block number. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0218}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-30 18:38:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg14741@s{hash}msg14741
@section 3 {tx}

  @p{««}I just updated the code/patch: @p{»»}

    @p{(li} monitoraddress allwallet @p{lt}url@s{gt} @p{li)}

  @p{««}... gets triggered for all transactions that go into your wallet.
  That includes 'change' transactions that can occur when you send
  somebody coins, which I expect will strike some people as a bug and
  others as an important feature. @p{»»}

  @p{««}And I combined the getblockby methods into one. I know I would've
  never remembered "is it getblockybycount or getblockbynumber or
  getblockbyheight or getblockbydepth" @p{--} I will remember
  "getblock".@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0219}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-09-30 21:44:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg14767@s{hash}msg14767
@section 3 {tx}

  @p{««}I should have been clear: this @p{(bf}is@p{bf)} a patch against the
  latest 'vanilla' svn.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0220}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-01 16:50:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1330.msg14866@s{hash}msg14866
@section 3 {tx}

  @p{««}A half-baked thought that's been bouncing around my head for the
  last couple of days: @p{»»}

  @p{««}One piece of functionality missing from bitcoin is the ability for
  somebody to prove that they own a certain bitcoin address. @p{»»}

  @p{««}I'm thinking that if there was a way to ask bitcoin to: @p{»»}

    @p{(li}1) Sign an arbitrary bunch of data with a bitcoin address'
    private key, and return the signature. @p{li)}

    @p{(li}2) Take a bitcoin address and signed data and verify that the
    signature is valid. @p{li)}

  @p{««}... then maybe that could function as the building block allowing
  webs of trust to develop in an application independent of 'core
  bitcoin'. @p{»»}

  @p{««}And secure, pseudo-anonymous communication between people who know
  only each other's bitcoin addresses. And probably a bunch of other
  interesting things I haven't thought of. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0221}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-02 12:52:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg14996@s{hash}msg14996
@section 3 {tx}

  @p{««}Today: a brand-new keypair (address) is created and added to your
  wallet when you have change. @p{»»}

  @p{««}Soon (I hope; I @p{(it}think@p{it)} satoshi is working on it...)
  bitcoin will pre-generate a bunch of addresses to use for change, and
  use one of them (and re-generate a bunch when it runs out). @p{»»}

  @p{««}I'd kind of like an option to put change back into one of the
  addresses it came from; that'd be simpler, quicker, and would make your
  wallet smaller... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0222}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-04 18:26:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1359.msg15339@s{hash}msg15339
@section 3 {tx}

  @p{««}There's a built-in mechanism for ensuring that this is never a
  serious problem: the more coins that are lost, the more valuable the
  remaining coins become. @p{»»}

  @p{««}And the more valuable something is, the more careful people are not
  to lose it. So there's a nice feedback loop that should naturally limit
  the number of coins lost. @p{»»}

  @p{««}If Bitcoin becomes the world's stable reserve currency then one
  bitcoin might end up being worth tens of thousands of dollars and we'll
  all get @p{(bf}much@p{bf)} more serious about backing up our wallets and
  keeping them secure. Or, I think more likely, most people will use a
  service that they trust to keep their coins backed up and secure...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0223}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-06 14:26:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg15650@s{hash}msg15650
@section 3 {tx}

  @p{««}I updated most of my git branches to svn rev 161 last night,
  including monitorreceived. That's easy: @p{»»}

    @p{(li} git svn fetch (but you have to have an "svn-remote" setup in
    your .git/config) @p{li)}

    @p{(li} git merge refs/remotes/svn/trunk (I could git rebase instead,
    but merge seems less magical to me) @p{li)}

    @p{(li} ... fix any merge conflicts and test then git commit, if
    needed (usually there are none) @p{li)}

    @p{(li} git push (to push up to github) @p{li)}

  @p{««}Repeated on each branch (I'll try to keep svn, svnTEST and
  monitorreceived up-to-date). @p{»»}

  @p{««}Keeping the patch file up-to-date is another couple of steps, and I
  could/should automate it. @p{»»}

  @p{««}doublec: thanks for the bug report, I'll look into it as soon as I
  get this machine setup. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0224}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-07 02:05:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1387.msg15764@s{hash}msg15764
@section 3 {tx}

  @p{««}Attached is a little patch that expands the getnewaddress RPC
  command so it can try to generate a "vanity" bitcoin address. @p{brk}
  E.g. I told it to generate an address with "gavin" in it, and it chugged
  away for an hour or two and came up with: @p{»»}

    @p{(li}@s{btcaddress} @p{li)}

  @p{««}This is recommended for fun and experimentation only; it takes a
  long time, and while it is trying to find an address with the right
  string in it no other RPC commands are accepted. Including 'stop'. @p{»»}

  @p{««}It'd be kinda cool (and would speed it up a lot) to make it
  case-insensitive. Or to match to an arbitrary regular expression. Or to
  make it spin off a separate thread and just return "working...." (and
  have the thread add the address to the wallet when it is finally found,
  labeled with the vanity string). @p{»»}

  @p{««}Maybe we should have a Best Bitcoin Address contest @s{cool} 

# ----------------------------------------------------------------------
@section 2 {ms0225}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-07 14:02:34 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1387.msg15837@s{hash}msg15837
@section 3 {tx}

  @p{««}RE: "wasting" addresses: @p{»»}

  @p{««}caveden is right, this patch generates and throws away lots and
  lots of potential bitcoin addresses. @p{»»}

  @p{««}But there are 2^160 possible bitcoin addresses, which is a really,
  really big number. The chances of BioMike generating an address that
  matches my "gavin" address before we're all dead is
  @p{(link}approximately zero@p{link)}. @p{»»}

  @p{««}And davidonpda: I haven't tried to figure out how long 10
  characters would take@p{--} it is exponential in the number of
  characters, so 10 characters would probably take years... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0226}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-07 15:12:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1387.msg15850@s{hash}msg15850
@section 3 {tx}

  @s{quotedtext}

  @p{««} But if it supported regular expressions "david.*on.*pda" would
  probably be found in a reasonable amount of time... @p{»»}

  @p{««}Of course, if you were unlucky it'd find something like
  1davidSpoonLApdaDDY13iu8 (not a real bitcoin address) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0227}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-07 18:25:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=909.msg15884@s{hash}msg15884
@section 3 {tx}

  @p{««}I'm a happy LastPass subscriber... and I hate to say it, but
  they're right. At this point there's no way the average consumer will
  use Bitcoin, even via a website like mybitcoin.com. @p{»»}

  @p{««}I think it will be a few years before bitcoin and bitcoin-related
  services are reliable and trustworthy enough for the average consumer.
  Don't get me wrong, I think bitcoin is a fantastic idea and has a good
  chance of being Really Important, but it is going to take a long for it
  to get accepted as a viable alternative to other payment solutions.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0228}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-07 23:05:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1387.msg15942@s{hash}msg15942
@section 3 {tx}

  @p{««}ByteCoin: cool! Are you finding alternative public keys for a given
  ECC private key? (are there multiple public keys for a given private ECC
  key??? I know very little about elliptic curve cryptography) @p{»»}

  @p{««}And to all: I couldn't resist, I updated the patch so it can search
  for a regular expression and so it starts a separate thread and doesn't
  monopolize the RPC thread. My machine is busy looking for a bitcoin
  address that matches '^1Gavin' right now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0229}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-09 19:31:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1408.msg16303@s{hash}msg16303
@section 3 {tx}

  @p{««}The only think I can think of is that the php fopen() call is
  timing out. Are you trying to generate coins? Does it get better if you
  stop generating? @p{»»}

  @p{««}Are you using PHP5 ? If you are, try creating a stream_context with
  a longer timeout (see @s{(link)} ). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0230}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-09 22:10:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg16341@s{hash}msg16341
@section 3 {tx}

  @s{quotedtext}

  @p{««}I automated updating/patching the monitorreceived patch, and just
  updated to Satoshi's latest: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}(use the "raw" link there for a link to latest version of the
  patch) @p{»»}

  @p{««}And I fixed the bug reported by doublec. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0231}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-11 18:56:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1434.msg16585@s{hash}msg16585
@section 3 {tx}

  @p{««}SVN rev 166 (bitcoin version 0.3.13.4) implements secure incoming
  SSL JSON-RPC connections to bitcoind or bitcoin -server on Linux and
  OSX. @p{»»}

  @p{««}I've created @p{(link}a wiki page@p{link)} with detailed
  instructions on how to configure bitcoin.conf for SSL JSON-RPC
  connections. @p{»»}

  @p{««}SSL support is enabled at compile time with the USE_SSL @s{hash}define,
  and is not enabled in the Windows makefiles because I'm told there
  are... issues... compiling full OpenSSL libraries on Windows (core
  bitcoin uses the openssl libcrypto library, this change requires the
  full libssl library). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0232}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-11 23:29:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1434.msg16633@s{hash}msg16633
@section 3 {tx}

  @s{quotedtext}

  @p{««}I don't know what the issues are@p{--} I do Mac/Linux these days (I
  don't do Windows). Does the precompiled fedora mingw32-openssl support
  ECSDA signatures? Can you give it a try and let us know if it works?
  (just add -DUSE_SSL to the Makefile and link with whatever libssl is
  called under mingw32) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0233}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-12 23:05:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1449.msg16771@s{hash}msg16771
@section 3 {tx}

  @p{««}Sure, there are a couple of tables in the back of
  @p{(link}Satoshi's bitcoin paper@p{link)} that calculate the chances
  based on what percentage of CPU work you're contributing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0234}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-14 13:38:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1460.msg16964@s{hash}msg16964
@section 3 {tx}

  @p{««}svn r167 is a tweaked makefile.unix that Xunie reports allows
  bitcoind to compile cleanly on Ubuntu 10.04 x86_64. @p{»»}

  @p{««}I tested on my Debian box and it does no harm; let me know if it
  breaks the build on any other unix flavors. @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0235}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-14 13:49:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1458.msg16965@s{hash}msg16965
@section 3 {tx}

  @s{quotedtext}

  @p{««} I bet you'd get a good approximation of hash rate if clients
  submitted their best (highest difficulty) hash every N minutes. Over a
  period of a few hours the average of all of those best hashes should be
  proportional to the client's hash rate (unless a client were somehow
  repeatedly very lucky or unlucky, but that would be extremely unlikely).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0236}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-15 18:39:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg17135@s{hash}msg17135
@section 3 {tx}

  @s{quotedtext}

  @p{««}Pass "allwallet" to monitoraddress and you'll get all transactions
  that put coins in your wallet. @p{»»}

  @p{««}RE: getting the data POSTed in PHP: Try: @p{»»}

  @p{««}json_string = http_get_request_body(); @p{»»}

  @p{««}Also, POSTing to @s{(link)} (create a postbin there first) is
  really useful for debugging. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0237}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-17 01:11:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1458.msg17276@s{hash}msg17276
@section 3 {tx}

  @s{quotedtext}

  @p{««}So... have clients send back their best N hashes (and the average
  should be N times better). @p{»»}

  @p{««}RE: detecting server cheating: Over a very long period of time,
  clients should be able to figure out approximately how many hash/sec the
  server's network is generating. So they should be able to detect blatant
  cheating. I should've taken statistics in college, seems like it'd be an
  interesting problem to work out the chances that a server is lying based
  on how many blocks it has generated over the last week... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0238}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-17 15:55:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1364.msg17377@s{hash}msg17377
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is pretty darn hard to make a billion dollars of gold (or paper
  money) virtually theft-proof, especially if you're worried that your
  government might decided it 'needs' some of it. @p{»»}

  @p{««}Assuming bitcoins are eventually worth billions of dollars, it will
  be easy to make a billion dollars of bitcoins virtually theft-proof.
  Heck, you could walk around with a billion dollars worth of bitoins on
  an encrypted memory stick in your pocket. @p{»»}

  @p{««}With a backup in a safe deposit box in Switzerland. That's MUCH
  better than gold or paper money. @p{»»}

  @p{««}I'm starting to think that bitcoin as a store-of-value might end up
  being more attractive than bitcoin as a medium-of-exchange. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0239}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-17 23:02:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1414.msg17428@s{hash}msg17428
@section 3 {tx}

  @p{««}RE: how many free keys are in the pool: @p{»»}

  @p{««}By default, there are at least 100 free keys in the pool, always.
  @p{»»}

  @p{««}When a key is taken out, if the number of free keys drops below 100
  (or the -keypool= number) another is generated. @p{»»}

  @p{««}Keys are put back if they're unused@p{--} for example, a key is
  needed for every miner hashing thread, so if you're on a 4-core machine
  and turn on coin generation and then turn it back off you'll wind up
  with 104 keys in the free pool. @p{»»}

  @p{««}But for most people most of the time there will be exactly 100 free
  keys. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0240}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-18 02:17:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1414.msg17441@s{hash}msg17441
@section 3 {tx}

  @p{««}Backup every 30 sendtoaddress or generatenewaddress and you'll be
  fine@p{--} you should always have at least 3 backup copies of all your
  keys. @p{»»}

  @p{««}If you're running a very busy service so backing up every 30 is too
  often, then run with -keypool=1000 and backup at least every 300
  sends/generates. @p{»»}

  @p{««}I worry about bitcoin accumulating too many features and not doing
  any of them very well. I suppose it wouldn't hurt to add an option so it
  automatically creates timestamped wallet backups... but should it erase
  old backups? (if it doesn't, I KNOW people will forget to erase them and
  will be upset when their disk fills up with wallet backups and they're
  left to figure out how to clean up the resulting mess). Should it
  encrypt them? What should it do if an automatic time-stamped wallet
  backup fails? When encrypted wallets are implemented, what should happen
  to old backups if the wallet encryption key is changed? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0241}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-18 02:27:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg17442@s{hash}msg17442
@section 3 {tx}

  @p{««}nBits is difficulty in 'compact' format? (if I recall correctly...)
  @p{»»}

  @p{««}It should be reported as floating-point 'difficulty', like you get
  from the 'getinfo' rpc command. @p{»»}

  @p{««}I will add that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0242}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-18 11:49:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1414.msg17494@s{hash}msg17494
@section 3 {tx}

  @s{quotedtext}

  @p{««} Keys in the keypool store when they're generated (and the oldest
  are always used first). Asking "what's the oldest key in the key pool"
  seems reasonable, and I think it would give you what you want@p{--} you
  could compare that timestamp to the timestamp of your last backup to see
  if you're covered. @p{»»}

  @p{««}Although if you're going to periodically check to see what the
  oldest timestamp is (or you're going to periodically check to see if
  bitcoin has written a new timestamped backup file or periodically check
  WHATEVER) then it seems simpler to me to just periodically always call
  backupwallet. Disk space and bandwidth is cheap these days... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0243}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-19 14:30:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1367.msg17616@s{hash}msg17616
@section 3 {tx}

  @p{««}This looks pretty interesting (in the US): @s{(link)} @p{brk} Print
  out a payment slip on a website, walk into a store and finalize payment
  in cash, website merchant gets immediately notified. @p{»»}

  @p{««}From their Terms of Service: "Please do not confuse our PayNearMe
  payment service with use of a credit card, debit card or pre-paid/loaded
  card. There is no extension of credit. And since there is no credit
  extended, there is no ability to challenge or cancel the transaction
  through a chargeback procedure." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0244}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-19 18:43:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1509.msg17642@s{hash}msg17642
@section 3 {tx}

  @p{««}Bitcoin version 0.3.13.05 (svn revision 168) adds the -testnet
  option to bitcoin/bitcoind, for testing or experimentation with
  worthless bitcoins on the TEST payment network. @p{»»}

  @p{««}This version is compatible with my old compile-time test network
  patch. Stuff you aught to know as you run this: @p{»»}

    @p{(li}A -testnet bitcoin will use the same bitcoin.conf file as
    regular bitcoin (unless overridden with the -conf= switch).@p{li)}

    @p{(li}The -testnet data directory is a "testnet" subdirectory in the
    regular data directory.@p{li)}

    @p{(li}A -testnet bitcoin listens for connections on ports 8333/8332,
    just like regular bitcoin, so you @p{(it}cannot@p{it)} run both
    -testnet and regular bitcoin at the same time on one machine.@p{li)}

    @p{(li}You can get play bitcoins from the TEST faucet at
    @s{(link)}@p{li)}

    @p{(li}testnet bitcoin addresses will not work on the regular bitcoin
    network, so it is impossible to accidently try to send real bitcoins
    to test address. However, regular bitcoin addresses @p{(it}are@p{it)}
    valid testnet addresses; it is possible to try to send testnet
    bitcoins to a regular bitcoin address (they will effectively be lost
    if you do that).@p{li)}

  @p{««}This will be very useful for anybody creating a web-based bitcoin
  service. You should be able to run bitcoind with the -testnet switch and
  no code changes to test your service with pretend, instead of real,
  bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0245}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-20 00:43:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1026.msg17691@s{hash}msg17691
@section 3 {tx}

  @p{««}RE: what's the use of b58_encode? It is dead code for this
  use@p{--} bitcointools (where I first implemented this stuff) uses it to
  translate from binary hash160 to human-readable bitcoin addresses. @p{»»}

  @p{««}RE: 27 character bitcoin addresses: I'm puzzled. There's a mismatch
  between the way bitcoin treats leading zeros (leading 1's when base58
  encoded) and the way my python code treats them. @p{»»}

  @p{««}ByteCoin: have you dissected the bitcoin code enough to explain how
  it decides how many leading zeros to add? According to my code,
  '14oLvT2' and '@s{btcaddress}' are the same bitcoin address
  (corresponding to the public key with a hash of all zero bytes). @p{»»}

  @p{««}But bitcoin only likes the 27-character '@s{btcaddress}' version.
  @p{»»}

  @p{««}I'll have to stare at the code some more tomorrow when I'm more
  awake.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0246}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-20 15:18:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1026.msg17787@s{hash}msg17787
@section 3 {tx}

  @p{««}Thanks theymos! I completely missed the leading-zero-bytes become
  leading-'1'-chars one-for-one. @p{»»}

  @p{««}I fixed the python code in the first message of this thread.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0247}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-20 19:16:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1520.msg17800@s{hash}msg17800
@section 3 {tx}

  @p{««}Ruby (or your Ruby JSON-RPC library) isn't setting the
  Authorization: HTTP header from the username:password in the URL. @p{»»}

  @p{««}I don't know anything about Ruby, but Mr. Google might be able to
  shed some light@p{--} you need to either set the Authorization: header
  yourself to do the HTTP Basic authentication (I seem to recall some Ruby
  code on the Wikipedia page about HTTP Basic Authentication) or, in some
  languages/frameworks there's a way of setting up a 'context' for HTTP
  connections so the authentication happens properly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0248}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-20 19:22:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1387.msg17801@s{hash}msg17801
@section 3 {tx}

  @s{quotedtext}

  @p{««} Awww, even replacing the lower-case-l's with 1's it ain't right:
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0249}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-20 19:33:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1267.msg17802@s{hash}msg17802
@section 3 {tx}

  @p{««}I implemented "validateaddress" in svn r169: @p{»»}

  @s{code}

  @p{««}No address version number; that wasn't trivial to do, so I didn't
  do it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0250}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-21 03:33:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1267.msg17849@s{hash}msg17849
@section 3 {tx}

  @p{««}RE: payment: @p{brk} If you really feel compelled to pay, send
  coins to the @p{(link}Faucet@p{link)}: @s{btcaddress} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0251}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-22 12:22:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1471.msg18051@s{hash}msg18051
@section 3 {tx}

  @p{««}I suspect (but am far from certain) that a couple of psychological
  factors in the average human mind makes deflation worse than inflation.
  @p{»»}

  @p{««}First, we've got an irrational attachment to "free" (see the book
  Predictably Irrational for experiments that show this). If money is
  deflating, I can just let it sit under my mattress for "free" @p{--} and
  that might be more attractive to me even though I'd get a better return
  by investing it. Investing ALWAYS looks like it costs something
  (brokerage commissions or lawyers fees or...). @p{»»}

  @p{««}And second, we've got an irrational aversion to loss and an
  irrational attachment to stuff that we own. Investment means opening
  yourself up to the possiblity of loss AND lending out something you own;
  I think a little bit of inflation helps overcome that irrationality, by
  building in a little loss if you stick your money under your mattress.
  @p{»»}

  @p{««}I wonder if somebody could devise a small-scale experiment to
  figure out if deflation is bad for investment, and/or measure the size
  of the effect... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0252}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-22 14:25:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1530.msg18074@s{hash}msg18074
@section 3 {tx}

  @p{««}Dhaw generated all of these coins on his (her?) own machines. @p{»»}

  @p{««}Unfortunately, either due to a bug or some oddness with Dhaw's
  network connections they were all generated on an alternate block chain.
  @p{»»}

  @p{««}The Bitcoin client really shouldn't allow coin generation until you
  have all of the blocks up to the last block checkpoint.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0253}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-22 15:19:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1536.msg18077@s{hash}msg18077
@section 3 {tx}

  @p{««}svn rev 172 (bitcoin 0.3.14.01) adds: @p{»»}

  @p{««}"testnet" and "keypoololdest" to getinfo output. testnet will be
  true if you are running on the test network. keypoololdest is the Unix
  timestamp of the oldest entry in the keypool. @p{»»}

  @p{««}For example: @p{»»}

  @s{code}

  @p{««} I also made bitcoin return proper HTTP Date: headers to better
  follow the HTTP spec. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0254}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-22 16:06:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1538.msg18082@s{hash}msg18082
@section 3 {tx}

  @p{««}I spent way too many hours yesterday trying to figure out why my
  Google App Engine code couldn't urlfetch from my -rpcssl bitcoin
  process, so I'm posting this to hopefully save somebody else from the
  frustration. @p{»»}

  @p{««}I made Bitcoin's HTTPS-JSON-RPC code fussy about what openssl
  ciphers it supports on purpose; by default, it doesn't accept SSLV1
  connections or older, weaker ciphers or hashing algorithms (like
  single-DES and MD5). @p{»»}

  @p{««}Surprisingly, Google's App Engine urlfetch service currently ONLY
  supports RC4/DES/MD5/SHA, so, by default, App Engine can't talk via
  https to Bitcoin. The workaround is easy (use the -rpcsslciphers= option
  to override the ciphers bitcoin will accept), and I'll document this on
  the @p{(link}rpcssl wiki page@p{link)}. @p{»»}

  @p{««}And hopefully Google will get with the program and support better
  encryption... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0255}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-25 21:08:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=665.msg18525@s{hash}msg18525
@section 3 {tx}

  @p{««}If you're running something like mybitcoin or mtgox or any other
  site that lets customers keep bitcoins in accounts, then
  one-customer-per-bitcoin-process isn't at all practical. To start with,
  every bitcoin process has a complete copy of the block chain...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0256}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-27 14:21:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1574.msg18850@s{hash}msg18850
@section 3 {tx}

  @p{««}I like the Bitcoin = ... ideas. Focus on the WHY, not the what or
  the how: @p{»»}

    @p{(li} @s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0257}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-27 18:41:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=665.msg18890@s{hash}msg18890
@section 3 {tx}

  @p{««}An impromptu brainstorm this morning in IRC chat (thanks
  everybody!) helped me think through a few issues for an "accounts" API.
  @p{»»}

  @p{««}The big idea: @p{»»}

  @p{««}Replace the JSON-RPC "label" API with the notion of "accounts".
  @p{»»}

  @p{««}What is broken about the current API? @p{»»}

    @p{(li}@p{(li} you can't get a list of all transactions that make up
    an account's balance @p{li)}

    @p{(li} if your bitcoin service has the notion of maintaining a
    balance for multiple customers then you end up mirroring information
    stored in the bitcoin wallet database. @p{li)}

    @p{(li} Mirroring is a problem because if the connection between your
    service and bitcoin @p{li)}

    @p{(li} fails at the wrong time (e.g. between sending a
    "sendtoaddress" and getting @p{li)}

    @p{(li} back "sent") your database can be out of sync with the bitcoin
    reality. @p{li)}

  @p{««}Problems this proposal does NOT tackle: @p{»»}

    @p{(li}@p{(li} multiple "wallets" for GUI bitcoin users @p{li)}

    @p{(li} improving anonymity by keeping "coins" from different people
    in different "wallets" @p{li)}

    @p{(li} "push" notifications from bitcoin when coins are received (or
    blocks generated) @p{li)}

  @p{««}NEW METHODS: @p{»»}

  @s{code}

  @p{««}CHANGES TO EXISTING METHODS: @p{»»}

    @p{(li}listreceivedbyaddress: return "account" instead of "label" in
    JSON-RPC result @p{li)}

    @p{(li}sendtoaddress: same API, but debits accounts as described below
    @p{li)}

  @p{««}METHODS RENAMED: @p{»»}

    @s{code}

  @p{««} @p{(so}METHODS REMOVED (deprecated):@p{so)} @p{»»}

    @s{code}

  @p{««} NOTES: @p{»»}

  @p{««}All existing routines would continue to be supported for a while
  (e.g. listreceivedbylabel would be kept as a synonym for
  listreceivedbyaccount, and would return both "account" and "label" in
  the JSON result). @p{»»}

  @p{««}Coins going into or out of the wallet that don't have an associated
  account will be associated with a default account (named the empty
  string: ""). So sum(account balances) will always equal server account
  balance. @p{»»}

  @p{««}Generated coins will be assigned to the default account when they
  mature. @p{»»}

  @p{««}sendtoaddress, and the GUI "send" button, will debit
  @p{(so}accounts starting with the default account (if it has a non-zero
  balance) and continuing in alphabetical (ascii) order.@p{so)}the default
  address, which will be allowed to go negative. @p{»»}

  @p{««}None of these changes will be visible in the graphical user
  interface. These changes are for people running bitcoind to support
  bitcoin-related services, not for end-users. @p{»»}

  @p{««}It would be nice to support transactions by batching up several
  commmands and ensuring that they either all succeed or all fail. But:
  this should be useful even without that feature. The cleanest way of
  doing that is JSON-RPC-2.0 "batch send", and that all can come in a
  later version. @p{»»}

  @p{««}@p{(so}Why remove setlabel? Because it is not clear what
  "setaccount @p{lt}bitcoinaddrress@s{gt}" means for old transactions that
  were received on that address@p{--} do they remain credited to the old
  account (confusing!) or does history get rewritten so they are credited
  to the new account (your accountant/auditor will surely
  protest!).@p{so)} @p{»»}

  @p{««}UPDATE: svn rev 188 implements most of this (all but
  gettransactions). And due to the disaster recovery scenario described
  below, 'setlabel' stays as 'setaccount'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0258}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-27 20:28:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1455.msg18905@s{hash}msg18905
@section 3 {tx}

  @s{quotedtext}

  @p{««} Is your Library/Application Data/ directory on a network-mounted
  volume? @p{»»}

  @p{««}Running bitcoin 0.3.13 on my OSX 10.6.4 Mac I'm not seeing any
  issues (it uses almost zero CPU when it is not generating, and 100%, but
  nice'ed, when it is). I don't see any DirectoryService CPU usage. @p{»»}

  @p{««}From what you've said, it looks like disk writes are chewing up
  lots of CPU time for some odd reason. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0259}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-28 14:12:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1598.msg19000@s{hash}msg19000
@section 3 {tx}

  @s{quotedtext}

  @p{««} Here's what could happen if somebody controls 50% of the
  nodes-that-are-accepting-connections: @p{»»}

  @p{««}I join the network with a node behind a firewall (so I only connect
  out to 8 nodes). I have a 1-in-256 chance that all my connections are to
  the cheater's nodes. @p{»»}

  @p{««}If I am very unlucky and all of my connections ARE to cheater
  nodes, then they can: @p{»»}

    @p{(li} refuse to relay my transactions to the rest of the network
    @p{li)}

    @p{(li} refuse to send me new "block created" messages @p{li)}

    @p{(li} send me only the addresses of other cheater nodes @p{li)}

  @p{««}They could also send me a bogus version of the block chain (well,
  bogus back to the last compiled-in checkpoint), but that would be easy
  to detect (number of blocks in the chain would be different from what
  everybody else sees). @p{»»}

  @p{««}They could NOT: @p{»»}

    @p{(li} modify/"damage" transactions @p{li)}

    @p{(li} hurt the vast majority of network nodes that have at least one
    connection to a non-cheater @p{li)}

  @p{««}I'm glossing over some details and possible attacks (e.g. if the
  attacker can hijack my internet connections @p{--} maybe I'm using a
  wireless network at a cafe @p{--} then I'm screwed because they can just
  redirect all of my connections to cheaters). @p{»»}

  @p{««}The bottom line is: make sure you have the right number of blocks
  (bitcoinwatch.com, for one, will tell you the block count). Don't do
  financial transactions on untrusted networks. And if your transactions
  don't go through after half an hour, restart bitcoin to connect to a new
  set of peers. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0260}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-28 14:54:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=665.msg19008@s{hash}msg19008
@section 3 {tx}

  @p{««}RE: one mandatory account: yes, the empty-string-named-account will
  be the "master" account. @p{»»}

  @p{««}RE: existing use cases: you should be able to do everything you can
  do now... EXCEPT for change the label of bitcoin address after it is
  created. Although associating a unique transaction ID to a bitcoin
  address seems like the wrong thing to do (since the same bitcoin address
  might be re-used for multiple transactions; your application might not
  allow that, but the addresses are publicly available in the block chain
  and you might be opening yourself up to unpleasant hacks if you don't
  consider what should happen if an old bitcoin address that you THOUGHT
  would be used only once receives a few bit-pennies....) @p{»»}

  @p{««}This morning I thought through what might happen in case of a
  disaster and a service using accounts had to restore from a wallet
  backup and some other, alternative source of transaction history (maybe
  application-specific transaction logs sent to an offsite logging
  server). @p{»»}

  @p{««}Assuming your backup is recent enough for your keypoolsize, no
  bitcoins will be lost, but account balances will be wrong because any
  "move", "sendfrom", and associate-bitcoin-address-with-account actions
  will be lost. @p{»»}

  @p{««}I've tweaked the proposed API to make recovery easier; I'm still
  thinking about "setlabel" @p{--} in the recovery case, you definitely DO
  want to be able to re-associate bitcoin addresses with accounts...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0261}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-28 18:48:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1514.msg19049@s{hash}msg19049
@section 3 {tx}

  @p{««}I wonder if we have already passed the point where a
  user-typed-in-arbitrary-key can be both secure from brute-force attacks
  and convenient to use. @p{»»}

  @p{««}If you make the key long enough to prevent brute-force
  try-every-possible-key attacks then typing it in gets really painful.
  @p{»»}

  @p{««}You can add proof-of-work, but attackers tend to have lots of CPU
  power (think botnets) and lots of time, and if you make the
  proof-of-work take more than a few seconds per attempt on a low-CPU
  device it gets really painful again. @p{»»}

  @p{««}I'm thinking some variation of wallet-on-a-USB-stick might be a
  more convenient and practical way of physically exchanging bitcoins.
  @p{»»}

  @p{««}I wonder if Ebay would let you sell USB sticks pre-loaded with
  Bitcoin, a snapshot of the block chain, and a "starter wallet" with X
  bitcoins in it... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0262}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-29 12:17:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1609.msg19130@s{hash}msg19130
@section 3 {tx}

  @p{««}grondilu, I think your premise is flawed@p{--} banishing the words
  "money" or "currency" will @p{(bf}not@p{bf)} help avoid future troubles
  with governments. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0263}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-29 18:10:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1609.msg19172@s{hash}msg19172
@section 3 {tx}

  @p{««}If you've got good crypto there's a fifth choice: @p{»»}

    @p{(li} 5. Give them dummy keys that unlock something innocuous.
    @p{li)}

  @p{««}Like a @p{(link}TrueCrypt-encrypted Hidden Volume@p{link)}
  filesystem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0264}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-10-29 19:30:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1574.msg19182@s{hash}msg19182
@section 3 {tx}

  @p{««}Bitcoin: money For the People, By the People. Not the Elites. @p{»»}

  @p{««}(eleven words@p{--} eleven is my favorite number!)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0265}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-01 15:37:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1624.msg19556@s{hash}msg19556
@section 3 {tx}

  @p{««}Looks good to me. @p{»»}

  @p{««}Try to connect then look at the end of bitcoin's debug.log; see if
  it is even getting the connection. @p{»»}

  @p{««}Also: did you restart bitcoind after adding the rpcallowip? The
  .conf file is only read at startup.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0266}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-01 17:05:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1624.msg19567@s{hash}msg19567
@section 3 {tx}

  @p{««}If bitcoin thinks the connection is not allowed, then it just
  ignores the connection attempt@p{--} nothing is written to debug.log.
  That's probably the right thing to do@p{--} otherwise somebody malicious
  could try to fill up your hard disk by repeatedly attempting to connect
  to port 8332. @p{»»}

  @p{««}If you can recompile bitcoind, the "ClientAllowed" routine in
  rpc.cpp is where a printf() to log connections could go. But I'd guess
  either you misspelled "rpcallowip" (I always type rcp instead of rpc...)
  or have a firewall blocking connections. @p{»»}

  @p{««}If you can ssh into the web server machine (or any other machine,
  actually), try: @p{»»}

    @p{(li}curl @s{(link)} @p{li)}

  @p{««}If you get "couldn't connect to host" then it is a firewall
  problem. @p{brk} If you get "Empty reply from server" then it is an
  rpcallowip problem. @p{brk} If you get an HTTP "Authorization Required"
  or "Authorization Failed" reply, then it is a username/password mismatch
  (those ARE logged in debug.log, though@p{--} grep for ThreadRPC). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0267}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-01 21:26:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1624.msg19599@s{hash}msg19599
@section 3 {tx}

  @p{««}Does it work if you (temporarily) set rpcallowip=* ? @p{»»}

  @p{««}And are you SURE you're running a bitcoind that supports
  rpcallowip? Run bitcoind getinfo, and check the "version" value returned
  (version 0.3.12 or later, if I'm reading the source correctly). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0268}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-02 14:21:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1624.msg19682@s{hash}msg19682
@section 3 {tx}

  @p{««}Ok, looks like two problems@p{--} if rpcallowip=* works, then maybe
  bitcoin thinks your IP is something else (or maybe there is a bug in the
  bitcoin rpcallowip code). Run this on the web server: @p{»»}

  @s{code}

  @p{««}As to why the PHP code isn't working@p{--} can you turn on
  error_reporting and get more information on what isn't working? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0269}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-03 14:55:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1647.msg19858@s{hash}msg19858
@section 3 {tx}

  @p{««}tentative: I don't get it. @p{»»}

  @p{««}You seem to be saying that somebody might be secretly working on a
  longer block chain, and all their hard work will be ruined because they
  won't be able to replace the block chain everybody else is using
  non-secretly because the block chain everybody else is using might get
  locked in. Ummm... yeah! Don't work on longer block chains in secret.
  @p{»»}

  @p{««}Either that, or you're saying Satoshi might accidently lock in a
  shorter block chain, and most people either not noticing or not caring.
  Umm... no, I don't see that happening. @p{»»}

  @p{««}The block chain lock-in check is only done when new blocks are
  accepted. Here is what would happen if Satoshi tried to commit a block
  lock-in that most of the network thought was shorter: @p{»»}

    @p{(li} 1. Imagine everybody downloads the new client with the bad
  lock-in. @p{brk} 2. Everybody who had the longer chain before ignores
  the lock-in, and continues to push the longer chain. @p{li)}

    @p{(li}(unless the longer chain contains a bad transaction@p{--} the
  chain is checked for bad transactions on startup, see
  CBlock::CheckBlock) @p{li)} 3. Newbies who are downloading the chain for
  the first time will hit the lock-in code, and will be running with a
  shorter chain. @p{»»}

  @p{««}There will be chaos as newbies generate blocks on the shorter
  chain, which only other newbies will accept. "oldies" will also continue
  to generate on the longer chain. Transactions will get added to both
  chains... and the "oldies" will beat Satoshi into submission. Unless
  there is a legitimate bug (like the overflow bug that inspired the block
  chain lock-in code in the first place). @p{»»}

  @p{««}If I am misunderstanding your concerns, please speak up. The number
  one development priority for bitcoin is security. If you have found a
  problem, please email or private-message Satoshi, or post here (besides
  possible network denial-of-service attacks@p{--} only email about those
  if you have a brilliant idea for how to prevent them...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0270}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-03 19:58:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1647.msg19899@s{hash}msg19899
@section 3 {tx}

  @s{quotedtext}

  @p{««} If Satoshi goes rogue, then the project forks. He has a very
  strong incentive (success of the project, growth of the value of the
  bitcoins he owns) not to do that. @p{»»}

  @p{««}If the SVN repo gets hacked, then we back out the hacked changes
  (that's easy to see; several of us look at every svn commit) and warn
  people who might have compiled with bad source to recompile. @p{»»}

  @p{««}I'm having trouble figuring out exactly what you would like to
  happen@p{--} is your complaint that you have a different definition of
  what "open source, peer-to-peer" means than the rest of us? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0271}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-03 20:26:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1610.msg19910@s{hash}msg19910
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's not right@p{--} the person paying you doesn't know your
  public key, they just know your bitcoin address (which is a 160-bit hash
  of your public key). @p{»»}

  @p{««}You can (and I have) send bitcoins to ANY 160-bit bitcoin address,
  whether or not there actually is a public/private keypair corresponding
  to that address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0272}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-03 23:04:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1455.msg19956@s{hash}msg19956
@section 3 {tx}

  @s{quotedtext}

  @p{««} Hmmm.... @p{»»}

  @p{««}At some point (bitcoin 0.9?) debug.log should contain only really
  critical errors/warnings. Right now it is more of a trace.log. @p{»»}

  @p{««}Flushing it after every write is the correct thing to do@p{--}
  otherwise critical information about what caused a crash could easily be
  lost. @p{»»}

  @p{««}Always closing and re-opening it is darn convenient if you've got a
  log-rotating script running... but working poorly with FileVault is
  definitely a bug. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0273}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-05 16:31:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1455.msg20209@s{hash}msg20209
@section 3 {tx}

  @s{quotedtext}

  @p{««}You already did. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0274}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-07 02:14:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1668.msg20419@s{hash}msg20419
@section 3 {tx}

  @p{««}Actually... prioritizing free transactions based on both amount and
  their "age" should make this attack toothless. @p{»»}

  @p{««}The basic idea is that if you're spamming lots of small free
  transactions, you'll be creating lots of brand-new "pennies" (you'll
  take an old 50BTC generated transaction, then split off a penny and get
  a penny and 49.99 change. Then split that 49.99 to get another penny,
  and so on and so on). @p{»»}

  @p{««}Sorting pending free transactions so that larger-value transactions
  and free transactions with inputs deep in the block chain ("old money")
  are given priority would let normal transactions go through. @p{»»}

  @p{««}The spammy transactions would still take up network bandwidth and
  disk space; if that becomes a problem, nodes could just ignore small,
  new transactions (not relay them) and let the nodes that are doing the
  spamming queue up and rebroadcast the transactions. They'd trickle into
  the network eventually, and in the meantime the spammer's bit-pennies
  would be tied up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0275}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 15:59:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1647.msg20643@s{hash}msg20643
@section 3 {tx}

  @s{quotedtext}

  @p{««} The test network (run bitcoin with the -testnet flag) is a
  different block chain, implemented so that the two chains never get
  confused. If anybody wants to start yet another block chain, it isn't
  technically hard, and won't cause any problems for "real bitcoin". @p{»»}

  @p{««}The hard part would be getting anybody to use your alternative; it
  would have to be better in some way other than just "I started the new
  chain, so I've got a lot of the
  easy-to-generate-at-the-beginning-coins." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0276}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 16:19:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1691.msg20645@s{hash}msg20645
@section 3 {tx}

  @s{quotedtext}

  @p{««} First: I've reviewed Bitcoin's networking code looking
  specifically for possible buffer overflow vulnerabilities, and found
  none. It is possible I missed something; please help review the code and
  let me or Satoshi know if you find anything suspicious. @p{»»}

  @p{««}Second: I don't think splitting the wallet handling code into a
  separate process will improve security at all. If there is code that can
  send the nicely-compartmentalized wallet handling code a command "Send
  XYZ bitcoins to address 1ABC...", and that code has a buffer overflow
  vulnerability in it, then you are just as vulnerable as today. @p{»»}

  @p{««}If your PC has been compromised, then you are in trouble; anything
  you do on your machine may be intercepted by a bad guy. Log into your
  bank account website@p{--} the bad guy might hijack your session and
  transfer money out. Start up bitcoin@p{--} the bad guy might inject
  keyboard and mouse events to send coins out. @p{»»}

  @p{««}Even if Bitcoin implemented multi-factor authentication before
  allowing wallet access ("scan your fingerprint and enter your password
  to send coins"), if your PC is compromised a bad guy could arrange to
  modify the bitcoin address that you say you want to send coins to, so
  you think you're authenticating a payment to Wally's Discount Center but
  you really authenticate payment to Doctor Evil's Empire. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0277}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 17:08:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1647.msg20650@s{hash}msg20650
@section 3 {tx}

  @s{quotedtext}

  @p{««} I agree@p{--} we're in the Wild West days of open-source currency.
  I expect people will get burned by scams, imitators, ponzi schemes and
  price bubbles.. @p{»»}

  @p{««}I tend not to worry about things that are out of my control; I
  don't think there's a whole lot that can be done about scammers,
  imitators, and ponzi schemes besides warning people to be careful with
  their money (whether dollars, euros or bitcoins). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0278}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 19:52:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1691.msg20698@s{hash}msg20698
@section 3 {tx}

  @s{quotedtext}

  @p{««} But again: if that clear interface includes a command to "send XYZ
  bitcoins to some address", then how is the separation making you more
  secure?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0279}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 20:57:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1691.msg20729@s{hash}msg20729
@section 3 {tx}

  @p{««}The behind-the-firewall nodes will need the following from an
  on-the-network bitcoind: @p{»»}

    @p{(li} 1. They need to be able to ask it "tell me about any
    transactions to these bitcoin addresses..." @p{li)}

    @p{(li} 2. They need to be able to send it a signed transaction and
    ask "Please broadcast this for me." @p{li)}

    @p{(li} Item 1 is implemented in my monitorreceived patch ( @s{(link)}
    ).@p{li)}

    @p{(li} Item 2 would be cool. Anybody want to design and develop an
    "accept transaction" patch? @p{li)}

  @p{««}All the other functionality needed (like generating public/private
  keys, generating and signing transactions) could be, and should be, in
  my opinion, be done as a project separate from bitcoin. Making the code
  small and self-contained and as secure as possible would be the goal; it
  could be re-used to create a type of lightweight client that ran on cell
  phones in addition to running behind corporate firewalls. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0280}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 22:00:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1691.msg20747@s{hash}msg20747
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think it is WAY too early to nail all that down; bugs in that
  code caused changes just a few months ago. @p{»»}

  @p{««}Just write the code, and when core bitcoin changes, be prepared to
  change your code. For the specific case we're talking about, you don't
  need to know all the possible ways scriptSig satisfies
  scriptPubKey@p{--} you just need to reverse engineer how the standard
  send-to-bitcoin-address works so you can sign your own
  send-to-bitcoin-address transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0281}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-08 23:57:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1668.msg20778@s{hash}msg20778
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, you can't, because every time you send them they become "new",
  and the priority is age multiplied by amount: @p{»»}

  @s{code}

  @p{««} (valuein is the size of the bitcoin input, age is @s{hash} of blocks
  deep, and txsize is the number of bytes the transaction takes up) @p{»»}

  @s{quotedtext}

  @p{««} Ummm... the more you mess around with the coins in your wallet,
  the newer they are, and the lower their priority (relative to everybody
  else who might want to get their transactions into the next block). I
  haven't thought deeply about it, but I bet simply leaving your coins as
  they are and making change as necessary will work out best. But please,
  create your own client and try to break things on the test network!
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0282}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-09 05:14:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1705.msg20899@s{hash}msg20899
@section 3 {tx}

  @p{««}If there's a c++ programmer out there looking for a good "get me
  feet wet" project involving Bitcoin, I think importing/exporting
  public/private keypairs (in one of OpenSSL's file formats) would be a
  really good choice. @p{»»}

  @p{««}The hard part is importing; you'd have to write code to re-scan the
  block chain to find transactions to/from the newly imported
  public/private keys, and add them to the wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0283}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-09 14:15:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1713.msg20989@s{hash}msg20989
@section 3 {tx}

  @p{««}Computers could get 1 billion times faster and Bitcoin's hashing
  and elliptic curve digital signatures will still be "safe." @p{»»}

  @p{««}2^256 is a really, really big number. @p{»»}

  @p{««}2^226 is also a really, really big number. It is a billion times
  smaller than 2^256, but still far and away big enough. @p{»»}

  @p{««}Even 2^160 (the size of the bitcoin address hash) is big enough.
  @p{»»}

  @p{««}Back-of-the-envelope: @p{brk} Lets say computers in a few years can
  do a quadrillion hashes per second@p{--} that's about 2^50
  hashes/second. How many seconds to find a SHA-256 hash collision? 2^205
  seconds. That is much longer than the age of the universe. @p{»»}

  @p{««}How long to find a bitcoin address hash collision? 2^130 seconds,
  which is 43,161,132,283,224,056,755,882,116,619,960 years. Also much,
  much longer than the age of the universe. @p{»»}

  @p{««}(actually, those numbers are the MAXIMUM time. Divide by two for
  the average time. Insanely big divided by two is still insanely big.)
  @p{»»}

  @p{««}You should be worried that some weakness in SHA-256 is found that
  allows hashes to be cracked other than by brute-force. And if you're
  worried about that, then it is dumb to switch to SHA-512 now@p{--}
  perhaps a flaw will be found in the entire SHA* family of hashing
  algorithms. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0284}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-09 19:36:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1668.msg21057@s{hash}msg21057
@section 3 {tx}

  @p{««}With davidonpda's help, I did some testing myself today with
  Satoshi's latest code changes (setting priority based on transaction
  age, bitcoin amounts in, and total transaction size in bytes @p{--} svn
  rev 176). @p{»»}

  @p{««}It behaved as expected, putting larger, older transactions ahead of
  the pennies being flooded into the network, so "normal" transactions
  will be confirmed promptly even if somebody decides to be a jerk and
  floods the network with transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0285}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-10 19:09:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1732.msg21353@s{hash}msg21353
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is 100% open source. Bitcoin relies on three other open source
  projects@p{--} wxWidgets (for the user interface), Boost (for geeky C++
  stuff), and OpenSSL (for cryptographic stuff). Those are all also 100%
  open source. @p{»»}

  @p{««}Improving The Fine Manual (and the website) will be an ongoing
  project; thanks for your questions. I agree that there is a lot of work
  to be done on the documentation front. Like most open source projects,
  most of us developers find writing code more fun than writing
  documentation or marketing material. @p{»»}

  @p{««} Satoshi is the main developer and person most in control of
  bitcoin (as said above). I've been the second-most active developer over
  the last month or so. @p{»»}

  @p{««}PS: if you have the time and feel like helping out... most of the
  documentation is in the Wiki, which anybody can edit. And constructive,
  specific suggestions for making the main bitcoin.org web page better are
  welcome, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0286}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-11 16:55:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1739.msg21534@s{hash}msg21534
@section 3 {tx}

  @p{««}All great ideas that I'm confident will eventually happen...
  assuming Bitcoin doesn't crash and burn for some reason (yes, I'm
  working hard on a technology I think has about a 30% chance will be made
  illegal or won't be "better enough" than alternatives to catch on or
  will overtaken by something even better or will have its peer-to-peer
  network overwhelmed with jerks mounting denial-of-service-attacks or
  will crash and burn for some reason I haven't thought of yet). @p{»»}

  @p{««}The "URL shortener" for stock Bitcoin would need to be a plug-in,
  where you give it one or more websites that provide URL shortening
  services (to get bitcoin addresses for email addresses or phone numbers
  or social security numbers (ok, SS@s{hash}'s would be a bad idea)). I don't
  think stock Bitcoin should or could do that, because that service means
  maintaining a centralized database, and trusting whoever runs that
  database not to suddenly, one day, decide to redirect all the bitcoins
  to themself and then retire to Bermuda. (or trust them not to get hacked
  so hackers get all those coffee-shop payments...) @p{»»}

  @p{««}That'd be another good, standalone project for a good C++
  programmer who wanted to do some Bitcoin-related programming... @p{»»}

  @p{««}I think the next big step for Bitcoin is a "lightweight client"
  that doesn't rely on a constant connection to the Bitcoin network,
  doesn't store the entire block chain, and doesn't try to generate
  blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0287}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-11 17:09:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1745.msg21538@s{hash}msg21538
@section 3 {tx}

  @p{««}Relevant threads from the past: @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} @p{li)}

  @p{««}I think a fully licensed online bitcoin exchange to/from US dollars
  via online credit card transactions (or another really quick, convenient
  mechanism) is critically needed. @p{»»}

  @p{««}Is it worth attempting: I've been very tempted! Unfortunately, to
  do it right and jump through all the legal hoops would require at least
  posting a $50,000 bond and probably thousands, possibly
  tens-of-thousands of dollars to hire lawyers to get all the paperwork in
  order. @p{»»}

  @p{««}And then I'd have to figure out how to accept credit card payments
  for bitcoins in a way that didn't open me up to massive fraud (maybe
  secondary approval via a phone call or text message). And convince a
  merchant account provider that I'd solved that problem and that I was
  trustworthy (which probably means another infusion of tens of thousands
  of dollars to cover potential fraud). @p{»»}

  @p{««}I think it is a great opportunity for somebody (or some company)
  who has had prior experience in the currency exchange business. The
  business model is clear and proven, and being the first fully licensed
  bitcoin exchange would have huge potential benefits if Bitcoin turns out
  to be a really successful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0288}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-12 19:55:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1765.msg21725@s{hash}msg21725
@section 3 {tx}

  @p{««}Probably against all of the credit card companies' terms of
  service; they don't like you taking money before "shipping the product."
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0289}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-13 16:18:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1771.msg21862@s{hash}msg21862
@section 3 {tx}

  @p{««}I'm a "bleeding heart libertarian." When I was young and naive I
  was "progressive/liberal," but now that I'm old and wise (or maybe just
  more cynical) I have a much greater respect for the positive incentives
  built-in to private markets, and the negative incentives built-in to
  government. @p{»»}

  @p{««}So I'm very sympathetic to the "it isn't fair that people with the
  fastest/most GPUs generate more bitcoins" point of view. @p{»»}

  @p{««}I agree that it would be more fair if every person started with an
  equal number of bitcoins. Work harder than average or provide a service
  that people value and you'd end up with more than you started with.
  Otherwise, you'd get bitcoin poor. @p{»»}

  @p{««}But I don't see a way to do that without some central authority
  deciding who is, and who is not, a 'person'. And I'm old and cynical
  enough to think that if there WAS a central authority making that
  decision, that central authority would very quickly devolve into a
  corrupt, favor-granting, power-grabbing institution. @p{»»}

  @p{««}"Oh, I'm sorry Mr. Andresen, for the Good of the System we are
  delaying the granting of your second child's Bitcoin Bounty until they
  have completed the mandatory consumer education classes, registered to
  vote, and have completed the voluntary 250 hours of America
  Freedom:Works! projects that they were assigned." @p{»»}

  @p{««}If you've got a brilliant, fool-proof, decentralized way of solving
  the identity problem, speak up! That'd be an even bigger breakthrough
  than bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0290}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-13 17:22:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1732.msg21873@s{hash}msg21873
@section 3 {tx}

  @p{««}How could I forget good old Berkeley DB? So old its approach
  (schemaless key-value store) is back in fashion... @p{»»}

  @p{««}So: FOUR other open source projects. Berkeley DB is also 100% open
  source. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0291}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-15 18:26:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1785.msg22118@s{hash}msg22118
@section 3 {tx}

  @p{««}Bad idea until we have secure DNS (DNSSEC) everywhere. @p{»»}

  @p{««}And maybe even a bad idea then; one slip of the fingers and your
  bitcoins might go to amazone.com instead of amazon.com. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0292}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-15 23:43:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1790.msg22171@s{hash}msg22171
@section 3 {tx}

  @p{««}So.... @p{»»}

  @p{««}I want to register a new domain name "gavin.bitdns" in this
  hypothetical bitdns system. @p{»»}

  @p{««}How do I do it? Run a BitX miner and hope that I generate a block
  sometime in the next week or three? Ummm... yuck! @p{»»}

  @p{««}Or I want to buy a domain from somebody; what does that look like
  in the bitdns system? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0293}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-16 13:02:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1805.msg22267@s{hash}msg22267
@section 3 {tx}

  @s{quotedtext}

  @p{««} Umm... how would they do that? @p{»»}

  @p{««}If even one machine remained connected to both the MiB and the rest
  of the network, then there will be no split. Transactions and blocks
  will continue to flow between them. @p{»»}

  @p{««}And if the MiB disconnect themselves from everybody else... then
  what they do has no effect on anybody else. @p{»»}

  @p{««}If the MiB have more than 50% of the block generating power then
  they can set the rules as you describe (refuse to put transactions with
  fees into the block chain, etc). If we didn't like it, we could write
  code that detected that they were "breaking the rules" (for example, we
  could reject generated blocks with no or very few free transactions,
  when we know there are old, free transactions waiting to go into a
  block), and work on our own "minority" chain. Convince the merchants and
  exchanges to run our code instead of the MiB code and the MiB can go
  play with themselves, we'll all happily continue trading with each other
  on the minority chain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0294}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-16 13:13:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1780.msg22268@s{hash}msg22268
@section 3 {tx}

  @p{««}ShadowOfHarbringer: don't be lazy! If you want to know if the
  lockins have been changed, it is easy to find out for yourself. @p{»»}

  @p{««}The blockchain checkpoints are in file main.cpp, around line 1,519:
  @p{»»}

  @s{code}

  @p{««} Even if you don't know C++ or don't know how to use subversion,
  you can check every release here: @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0295}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-18 00:18:11 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=292.msg22503@s{hash}msg22503
@section 3 {tx}

  @p{««}I just committed a change to svn to the way debug.log is written
  that means you need to change your logrotate configuration. @p{»»}

  @p{««}Why the change: before, bitcoin was opening and closing debug.log
  on every print. That caused it to be unusable on Macs running FileVault
  (and slower than it aught to be on various other systems). @p{»»}

  @p{««}After subversion rev 183, bitcoin will keep debug.log open and just
  append to it. @p{»»}

  @p{««}If you're rotating logs using the unix logrotate command, just add
  'copytruncate' to its configuration file and the right thing will
  happen. I changed the example in my post above.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0296}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-18 00:24:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1820.msg22504@s{hash}msg22504
@section 3 {tx}

  @p{««}It'd been a while since I shot myself in my foot, so I guess I was
  overdue. @p{»»}

  @p{««}Anyhow, on my third attempt I think I've got it right@p{--} I fixed
  a bug that was causing Bitcoin to be unusably slow on Macs running
  FileVault (the built-in filesystem encryption on the Mac). @p{»»}

  @p{««}The problem was Bitcoin opening and then closing the debug.log file
  on every write. After a couple of "too clever for my own good" solutions
  that broke, or could break, in interesting ways, the code now opens
  debug.log and simply keeps it open, constantly appending to it. @p{»»}

  @p{««}If you run a bitcoind server, see the "@p{(link}don't forget to
  rotate your logs@p{link)}" thread for what you need to do for log
  rotation to work properly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0297}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-18 18:48:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1833.msg22646@s{hash}msg22646
@section 3 {tx}

  @p{««}Bitcoins are 50 times more valuable today than when I first heard
  about them six months ago. If they just double in the next six months,
  they'll have risen 100-fold in a year. @p{»»}

  @p{««}It seems like a good idea to me to come to a consensus now about
  when to "move the decimal points" @p{--} when should the Bitcoin program
  allow you to specify payments with more than two decimal places (e.g.
  "pay Gavin 0.001 BTC for his thoughts") ? @p{»»}

  @p{««}When should the Bitcoin program assume you're entering payments in
  'millicoins' or 'microcoins' ? @p{»»}

  @p{««}And when should all of the internal minimums (e.g. smallest
  transaction fee or the trigger for the 'micro-transaction spam
  prevention') be lowered? @p{»»}

  @p{««} Here's a straw-man off the top of my head: @p{»»}

  @p{««}When Bitcoins are worth more than about ten dollars (or euros)
  each, I think it'll be time to allow sub-bit-penny payments. And I think
  the "smallest free transaction" limit (and other internal minimums)
  should move in lock-step with that change. @p{»»}

  @p{««}When 1 Bitcoin is worth somewhere around $100 (in 2010 dollars), I
  think it'll be time for the client to switch to millicoins (e.g. .001
  BTC), so if I'm buying a paperback book it costs 50 milliBTC instead of
  .05 BTC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0298}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-19 15:55:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1844.msg22822@s{hash}msg22822
@section 3 {tx}

  @p{««}daveout's code isn't quite right (because he based it on an earlier
  version of my python code). @p{»»}

  @p{««}Corrected version of the python code is in @p{(link}this
  thread@p{link)}. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0299}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-19 21:58:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1843.msg22926@s{hash}msg22926
@section 3 {tx}

  @p{««}Good article! @p{»»}

  @p{««}And good job jgarzik on answering questions! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0300}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-20 14:57:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1854.msg23068@s{hash}msg23068
@section 3 {tx}

  @p{««}Everybody is looking for: @p{»»}

  @p{««}h = f(x), where h @p{lt} TARGET @p{»»}

  @p{««}I think you're asking if there is some weakness in SHA256 (or
  hashing in general) that can make solving that problem trivial. @p{»»}

  @p{««}It seems unlikely to me, but I'm not a professional cryptographer.
  If TARGET were '4', then the problem is equivalent to: @p{brk} h = f(x)
  where h = 0 OR h=1 OR h=2 OR h=3 @p{»»}

  @p{««}Maybe there's some tricky method that reuses work and makes solving
  the TARGET=4 case more than 4 times easier than solving for TARGET=1
  (which is "find this specific hash")... but I just don't see that doing
  anything more than what has already been pointed out in previous posts:
  it is just a quicker way of hashing, so difficulty would go up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0301}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-21 14:04:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1869.msg23306@s{hash}msg23306
@section 3 {tx}

  @s{quotedtext}

  @p{««}The keypool IS used for coin-generation transactions. @p{»»}

  @p{««}And the way it is implemented, it should never throw away keys. If
  I recall correctly, there is a very small chance if you lose power or
  bitcoin crashes a key from the keypool could be used twice. But that has
  no bad effects, it is just very unusual.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0302}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-21 14:08:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1833.msg23310@s{hash}msg23310
@section 3 {tx}

  @s{quotedtext}

  @p{««}Wasn't me. I don't remember Satoshi ever writing something like
  that, but I'm really good at forgetting things. @p{»»}

  @p{««}I agree with ribuck, if we ever need more than 21quadrillion
  bit-atoms, encoding more using the unused high bits in the 64-bit number
  will work nicely. @p{»»}

  @p{««}That would be a very nice problem to have. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0303}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-21 14:27:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1852.msg23315@s{hash}msg23315
@section 3 {tx}

  @s{quotedtext}

  @p{««} I worry that the correct analogy is: @p{»»}

  @p{««}Typing a password every time you use your bitcoin wallet is like
  putting padding your car's steering wheel instead of wearing a seatbelt.
  It might make you feel safer, but it is a false sense of security. @p{»»}

  @p{««}Good security @p{(bf}is@p{bf)} hard. If you're not computer savvy,
  then you've probably already got spyware and trojans on your system, and
  running bitcoin on a system infested with spyware and trojans is a bad
  idea. Period. @p{»»}

  @p{««}I think an online service that takes care of wallet security for
  you is a much better solution for non-geeks like my mom. @p{»»}

  @p{««}All that said: As my personal bitcoin wallet gets more valuable, I
  get more nervous. I would like to be able to export some of the value in
  my wallet onto a USB thumb drive and then put that thumb drive in my
  safe deposit box (along with a backup, gpg-encrypted copy that I'd keep
  in the fire safe in my basement). @p{»»}

  @p{««}Another analogy: I keep most of my money in the bank; I don't have
  piles of cash or gold in my house. I will do the same for my bitcoins,
  keeping only enough in my online, connected, possible-to-hack wallet to
  use day-to-day. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0304}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-22 16:32:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg23575@s{hash}msg23575
@section 3 {tx}

  @p{««}I just committed a minimal implementation of "accounts", as
  discussed a few weeks ago in @p{(link}this thread@p{link)}. @p{»»}

  @p{««}If you're using the command-line or JSON APIs, you should be aware
  of a change that might make your code break: the sendtoaddress method
  will return a hexadecimal transaction id (256-bit hash) instead of the
  string 'sent'. @p{»»}

  @p{««}All of the 'label' commands have been renamed; the old names are
  still supported but are deprecated and may eventually be removed. @p{»»}

  @p{««}If you're developing a web service using bitcoin, the new
  'sendfrom' and 'move' methods can make it much easier to keep track of
  customer account balances. The API is intended to be used like this:
  @p{»»}

  @p{««}Create a new account: just generate a unique account ID in your
  application (maybe customer's login name). @p{»»}

  @p{««}Get a bitcoin receiving address associated with the account: @p{»»}

    @s{code}

  @p{««} Note: multiple bitcoin addresses can be associated with the
  account @p{»»}

  @p{««}Send bitcoins from the customer's account: @p{»»}

    @s{code}

  @p{««} Will fail if @p{lt}fromaccount@s{gt} doesn't have enough bitcoins
  (otherwise returns transaction id) @p{»»}

  @p{««}Move bitcoins between accounts: @p{»»}

    @s{code}

  Will fail if @p{lt}fromaccount@s{gt} doesn't have enough bitcoins @p{»»}

  @p{««}Report account balance: @p{»»}

    @s{code}

  @p{««} The empty-string account is a little bit special. Any coins
  received on bitcoin addresses not associated with other accounts is
  credited to it, and coins sent via the (old) sendtoaddress method are
  debited from it. @p{»»}

  @p{««}Coming soon, I hope, will be a gettransaction @p{lt}txid@s{gt}
  method to return details of a transaction that is stored in your wallet
  (like which account it was to or from and whether or not transaction
  fees were paid). And listtransactions, to get an accountant-friendly
  itemized list of all the transactions that went into any particular
  account balance. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0305}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-22 16:55:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg23582@s{hash}msg23582
@section 3 {tx}

  @p{««}The send methods don't try to be clever; they always broadcast
  transactions. @p{»»}

  @p{««}If you want that behavior, be clever yourself: call getaccount
  @p{lt}bitcoinaddress@s{gt} before calling send, and then call move
  instead of send* if you find out the bitcoinaddress is one of yours.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0306}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-22 17:50:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg23589@s{hash}msg23589
@section 3 {tx}

  @s{quotedtext}

  @p{««} The "" (empty-string-named) account is allowed to have a negative
  balance. You can sendtoaddress as long as the entire wallet has enough
  coins. @p{»»}

  @p{««}Accounts (like labels before them) are just a useful accounting
  mechanism. The rest of the network doesn't know or care what accounts
  you have. And although transactions to and from the wallet are credited
  or debited to accounts, all of the 'coins' get mixed together in the
  wallet, there is no notion of "this account received 100 bitcoins in
  this transaction, so we should use those for that transaction out..."
  @p{»»}

  @p{««}For example: @p{»»}

  @p{««}100 bitcoins are sent to an address associated with Account A. A's
  balance is now +100. @p{brk} 50 bitcoins are sent to an address
  associated with B. B's balance is now +50. @p{brk} 100 are moved from A
  to B. A has zero, B has 150. @p{»»}

  @p{««}B is allowed to send 150, but it won't necessarily be the 100
  originally sent to A and the 50 sent to B; if other accounts have
  received coins (transactions), those might be sent instead. @p{»»}

  @s{quotedtext}

  @p{««} bitcoin doesn't care (use any valid JSON string for the name), and
  the rest of the network doesn't care, so use account names that make
  sense for your application. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0307}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-23 01:03:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg23695@s{hash}msg23695
@section 3 {tx}

  @s{quotedtext}

  @p{««} There never was a way to place labels on a per-transaction basis.
  It was always a one-label-to-multiple-bitcoin-addresses association.
  @p{»»}

  @p{««}But all of the old label functionality is still there, just
  renamed. You should be able to do anything you were doing before. @p{»»}

  @p{««}However, you might think you were doing something that you weren't
  actually doing. There was no way to label/name particular transactions
  before (just addresses). @p{»»}

  @p{««}RE: the empty string as the default account: None of this is (or
  will be) visible to GUI users, and if you're a programmer using the JSON
  or the command-line interface SURELY you know how to quote strings.
  @p{»»}

  @p{««}RE: hierarchical wallet keys: Huh? If you want trivial searching
  and grouping... then export the info into a database and use SQL. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0308}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-23 17:10:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1860.msg23851@s{hash}msg23851
@section 3 {tx}

  @p{««}As a veteran of the premature standardization trenches (I wrote
  most of the ISO/IEC 14772-1 "VRML97" specification before I changed my
  last name from "Bell" to "Andresen")... I agree with foreverdamaged. It
  is too early to try to create a formal specification. @p{»»}

  @p{««}However, it think writing informal specifications documenting how
  bitcoin works right now is a great idea, and will be really helpful when
  it @p{(bf}is@p{bf)} time to go through some standardization process.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0309}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-23 17:43:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1899.msg23860@s{hash}msg23860
@section 3 {tx}

  @p{««}What error did you get, farmer_boy? The only errors I see in the
  server's logs are "rate limit" errors. @p{»»}

  @p{««}The Faucet tries hard to prevent people from cheating and using it
  more than once; unfortunately, that means if somebody who "looks like
  you" uses the Faucet before you, you might be prevented from getting
  your coins. If that happens, try again a day later. @p{»»}

  @p{««}I've been thinking about implementing a two-tiered Faucet: one that
  gives out a smaller number of coins and just requires you solve the
  CAPTCHA (and has all the current anti-cheating measures in place; there
  @p{(bf}are@p{bf)} one or two people still people cheating, but they're
  only able to get a few bit-pennies an hour, and they're going through an
  amazing amount of trouble to do it). @p{»»}

  @p{««}And another that gives out a larger number of coins if you login
  with a valid Google account. Getting tens or hundreds of Google accounts
  is harder than solving CAPTCHAS. @p{»»}

  @p{««}But if I did do that... I'd get accused of implementing the Faucet
  as a sneaky way of stealing Google account email addresses. @p{»»}

  @p{««}Sigh. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0310}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-23 23:33:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1035.msg23937@s{hash}msg23937
@section 3 {tx}

  @p{««}Designing and implementing user-friendly wallet backup for the GUI
  bitcoin seems like it would be a great little project for somebody who
  knows C++ and knows, or is willing to learn, wxWidgets programming. The
  non-GUI code already has the 'backupwallet' RPC method, and 'getinfo'
  will tell you the age of the oldest key in your keypool. @p{»»}

  @p{««}For extra credit, the code could keep track of the last successful
  backup and warn you that it is time to backup again when the keypool age
  gets close to the last backup time. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0311}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-24 02:27:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1899.msg23980@s{hash}msg23980
@section 3 {tx}

  @p{««}MrFlibble: "Fair" is one set of coins (however many the Faucet is
  giving out at the time@p{--} hopefully, bitcoins will continue to become
  more valuable, and I'll give out fewer over time...) per person. @p{»»}

  @p{««}I like the postcard idea, although I'm not willing to type in
  bitcoin addresses written on postcards! @p{»»}

  @p{««}Hmm... any stamp collectors here? Paying people bitcoins to send
  you postcards (with stamps on them) might be really fun... @p{»»}

  @p{««}And re: using OpenID instead of a Google Account: that'd be easy to
  implement, but way too easy for cheaters (who can just be their own
  OpenID provider and give themselves as many OpenIDs as they want). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0312}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-28 15:52:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1877.msg25117@s{hash}msg25117
@section 3 {tx}

  @p{««}So... 8 years ago some bittorrent folks came up with the magnet:
  URI scheme. @p{brk} And yet I don't run across many magnet links as I
  browse the web. @p{»»}

  @p{««}As I browse the web I run into exactly three URI schemes: http,
  https, and mailto. @p{»»}

  @p{««}I think a @p{(link}bitcoin mime type@p{link)} will be easier to
  implement and is likely to be more successful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0313}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-29 01:12:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1992.msg25253@s{hash}msg25253
@section 3 {tx}

  @p{««}I saw a version of this at a presentation of a local "time dollars"
  group... and I think their arguments go wrong at a couple of places.
  @p{»»}

  @p{««}First, wealth creation is limitless (we continue inventing more
  efficient ways of doing things and new things to spend our time and
  money on), so it's simply not true that an ever-increasing money supply
  (created via debt) is unsustainable. If there was some way of pegging
  the creation of the 'right' amount of money to the overall amount of
  wealth being created, then we'd get stable prices and the 'right' level
  of investment. @p{»»}

  @p{««}And second, the argument is that the system is stacked against the
  borrower@p{--} that it is designed so that there's never enough money
  for everybody to pay off their debts. So if I WANT to pay back my debt,
  I'll find out there's a money shortage, and I won't be able to. @p{»»}

  @p{««}That ignores the fact that I can walk away from my debts via
  bankruptcy. And the fact that many loans are secured with some form of
  collateral, which lenders accept in lieu of cash. Borrowing/lending is
  not an entirely closed system, and, ideally, lenders have to be smart
  and fund borrowers who are creating real wealth. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0314}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-29 20:56:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2007.msg25464@s{hash}msg25464
@section 3 {tx}

  @p{««}I haven't tested my 'master' bitcoin-git branch in a while, I
  wouldn't be surprised if the new 'accounts' code in the subversion tree
  broke something. @p{»»}

  @p{««}Which not-in-subversion features are you using? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0315}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-29 21:07:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1877.msg25470@s{hash}msg25470
@section 3 {tx}

  @s{quotedtext}

  @p{««}From the @p{(link}previous thread@p{link)}: @p{»»}

  @s{quotedtext}

  @p{««} Implementing something that won't even work on our own forums
  would be a bad idea, in my humble opinion. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0316}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-29 21:28:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1992.msg25476@s{hash}msg25476
@section 3 {tx}

  @s{quotedtext}

  @p{««}I grabbed the "Digital Coin Technology" pdf file. @p{»»}

  @p{««}It looks to me like it fails in the second paragraph: @p{»»}

  @s{quotedtext}

  @p{««} If the DigitalCoin software can read the serial number, then so
  can other software. It is simply not true that "The DigitalCoin software
  alone can ..." @p{»»}

  @p{««}Either you have a central server running the DigitalCoin software
  and you have to trust that the people running that server won't
  double-spend DigitalCoins. @p{»»}

  @p{««}Or... you have Bitcoin, where the "serial numbers" are the public
  keys of coin generation transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0317}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-29 23:54:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2010.msg25526@s{hash}msg25526
@section 3 {tx}

  @p{««}... and the person you hand the keys to will have to trust that you
  didn't keep a copy of them (or if you did, that you won't spend them
  before they do). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0318}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-30 05:12:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2012.msg25644@s{hash}msg25644
@section 3 {tx}

  @p{««}I agree with FreeMoney. @p{»»}

  @p{««}I think that as long as the generation reward is predictable there
  will be essentially no problems; people are smart, and will plan ahead.
  I predict the 100 blocks after the generation reward gets cut to 25BTC
  will be generated in the same time as the 100 block generated before the
  reward cut, within, oh (pulling a number out of my ear) 20% plus or
  minus. @p{»»}

  @p{««}I'm reminded of the Y2K hype back in 2000; that was a predictable
  event that turned out to be a non-event. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0319}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-30 19:52:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2025.msg25819@s{hash}msg25819
@section 3 {tx}

  @p{««}The "accounts" feature (to replace "labels") is done for now:
  listtransactions and gettransaction are implemented, and move, sendfrom,
  and getbalance @p{lt}account@s{gt} are enabled. @p{»»}

  @p{««}This should make implementing web services much easier; you can
  assign each customer their own 'account' and rely on bitcoin to keep
  track of exactly how many bitcoins they have, have it return a list of
  the customer's last N transactions, etc. @p{»»}

  @p{««}This is a minimal implementation @p{(bf}on purpose@p{bf)}@p{--} for
  example, gettransaction doesn't return every possible bit of information
  you might want to know about a transaction, and will only return
  information for transactions in your own wallet. We are trying to think
  ahead and not add features that will be broken or taken away when
  bitcoin supports running in a 'lightweight client' mode, without access
  to the entire bitcoin transaction history. @p{»»}

  @p{««}I've updated the @p{(link}API wiki page@p{link)} with the new
  methods. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0320}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-11-30 19:58:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2007.msg25821@s{hash}msg25821
@section 3 {tx}

  @s{quotedtext}

  @p{««} I just browsed back through the git commit history, and I don't
  see any interim commits of the account code (I was working in local
  branches, and didn't push interim versions up). @p{»»}

  @p{««}davout: You should try dumping your wallet using the latest
  bitcointools (dbdump.py @p{--}wallet), it will tell you if it finds
  weird key values in there. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0321}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-01 13:29:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2025.msg25876@s{hash}msg25876
@section 3 {tx}

  @s{quotedtext}

  @p{««} You can continue to use accounts as labels, create an
  each-address-gets-one-label, and map addresses@p{--}@s{gt}user in your
  database. @p{»»}

  @p{««}However, your application will be faster and simpler if you let
  bitcoin do the addresses@p{--}@s{gt}user mapping (one account per user),
  and store address@p{--}@s{gt}user-specified-label in your database.
  @p{»»}

  @p{««}The bitcoin 'getaddressesbyaccount' method will give you the
  addresses@p{--}@s{gt}user relationship, and all the accounting becomes
  much easier (listtransactions gets you all the transactions associated
  with a particular user, etc). @p{»»}

  @s{quotedtext}

  @p{««} The label methods still work, call the corresponding account
  methods (e.g. call setlabel @p{lt}bitcoinaddress@s{gt} and it calls
  setaccount), but are deprecated, so they don't show up in the help and
  will eventually be removed. @p{»»}

  @p{««}The only 'potentially breaking change' is the sendtoaddress
  function, which now returns a transaction id instead of the word 'sent'.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0322}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-01 14:00:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2012.msg25885@s{hash}msg25885
@section 3 {tx}

  @s{quotedtext}

  @p{««} Y2K was a non-event exactly because it was predictable and so lots
  of people did lots of work to make sure nothing terribly bad happened.
  @p{»»}

  @p{««}My point is only that the block @s{hash}210,000 switchover will, I think,
  be exactly the same. An entirely predictable event that people will plan
  and prepare for. It will be a significant event only for the very small
  minority of people who have to do the planning and preparing. @p{»»}

  @p{««}RE: complacency: I think we're a lot better at getting complacent
  about random events (like earthquakes and hurricanes) than "this is
  absolutely 100% certain to happen on or around this date" events. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0323}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-01 14:46:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2029.msg25905@s{hash}msg25905
@section 3 {tx}

  @p{««}I wrote this @p{(link}three years ago@p{link)}, and I'd still like
  to see something like it implemented. Now we've got Bitcoin,
  implementing it might be much easier; I'd love to see a bitcoin
  bbs/forum that uses these ideas to reward thoughtful, high-quality
  discussion (replace "email list" everywhere below with "discussion
  forum" and I think it all still works): @p{»»}

  @p{««} @p{hrule} I was listening to "@p{(link}The Ethics of
  Liberty@p{link)}" yesterday, and it got me thinking about email lists.
  @p{»»}

  @p{««}Most email discussion lists seem to suffer from a Tragedy of the
  Commons@p{--} there's not a whole lot of motivation for people posting
  their opinions to think twice about spouting off, or going on and on and
  on, or otherwise polluting the list with stuff that the subscribers to
  the list might consider junk. @p{»»}

  @p{««}There are a couple of solutions to these kinds of problems. You can
  try to set up some kind of policing system, with trusted moderators
  given the power to bless posts, ban people, etc. You need really
  thick-skinned, generous-hearted, even-tempered moderators for that to
  work. @p{»»}

  @p{««}A solution that works in the real world that hasn't been tried for
  the email mailing list problem (as far as I know) is some kind of
  economic system, where the common resource is given a value and anybody
  wanting to use the resource must pay rent (which is then used to
  maintain the resource). @p{»»}

  @p{««}So, here's a thumbnail sketch of how this might work for an email
  mailing list: @p{»»}

  @p{««}Create an artificial currency. If you have enough of this currency,
  you're allowed to post messages to the list. Longer posts cost more than
  shorter posts. @p{»»}

  @p{««}Everybody starts with some amount of this currency. Everybody is
  allowed to use it themselves, give it away, or sell it (for real money!)
  to people who want to use it to post messages. @p{»»}

  @p{««}Every message posted includes ways of: @p{brk} - Tagging the
  message as "Worthwhile" @p{--}@s{gt} transfers currency from your
  account to the poster's account. @p{brk} - Tagging the message as "Waste
  of my Time" @p{--}@s{gt} transfers currency from poster's account to the
  common pool of currency. @p{»»}

  @p{««}The amount of currency in the system is tied to the desired message
  traffic. We all have a limited attention span; basically, the trick will
  be to create an artificial economy so that the people who contribute
  positively are encouraged to contribute more, and people who "pollute"
  are punished. @p{»»}

  @p{««}Currency goes into the system every day (again, based on desired
  message traffic per day). Some is assigned to new people signing up for
  the list, and the rest evenly distributed to everybody already on the
  list. @p{»»}

  @p{««}"Lurkers" on the list could either hoard their currency, offer to
  sell it, or give it away to people from whom they want to hear
  more.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0324}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-01 21:23:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2029.msg26014@s{hash}msg26014
@section 3 {tx}

  @s{quotedtext}

  @p{««} Excessive, lazy quoting (like this message!) should also be
  discouraged.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0325}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-02 02:44:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=672.msg26112@s{hash}msg26112
@section 3 {tx}

  @p{««}The JSON-API wiki page describes all the methods: @s{(link)} @p{»»}

  @p{««}The wiki needs a good re-organization; anybody want to volunteer to
  revamp the Start page? @p{»»}

  @p{««}RE: comment and comment-to : they're stored in your wallet along
  with the transaction, but not sent over the network. The new
  gettransaction and listtransactions methods will return them (as
  "message" and "to"). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0326}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-02 13:54:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2041.msg26202@s{hash}msg26202
@section 3 {tx}

  @p{««}I'm mostly libertarian, although I'm sure the more pure
  libertarians here would call me a fuzzy-headed socialist. @p{»»}

  @p{««}Anyway, for seatbelts: @p{»»}

  @p{««}Be careful comparing rich, Western countries to poorer countries.
  As we get richer we value personal safety more, so we demand things like
  seat belts and air bags in our cars. @p{»»}

  @p{««}I believe that our politicians see that demand, then jump on the
  bandwagon and pass laws that basically everybody thinks are a Good Idea,
  and then take credit for making us safer. @p{»»}

  @p{««}I'm not 100% certain that is true for seatbelts; I haven't actually
  looked at the graph of traffic fatalities over time, to see if there is
  a bend in the curve when seatbelt legislation is passed. @p{»»}

  @p{««}For smoking: we shouldn't be allowed to do things that hurt, or
  have a "reasonable" chance to hurt, other people. Personally, I waffle
  back and forth over whether second-hand smoke imposes an unreasonable
  chance of harm on others. @p{»»}

  @p{««}I've looked at the evidence, and it seems that only people exposed
  to repeated, long-term secondhand smoke have an increased risk of death.
  Like spouses or children of smokers. And the smoking bans NEVER apply to
  private residences. So again, I think politicians may just be jumping on
  the bandwagon and passing feel-good laws that do no good (although in
  the last couple of days I read that it looks like grotesque images on
  cigarette packs ARE measurably effective at reducing smoking). @p{»»}

  @p{««}For vaccinations: "herd immunity" from vaccinations is a true
  "public good," in the strict @p{(link}economic definition of "public
  good."@p{link)} I think it is fine and dandy for the government to
  provide true public goods, either directly or (usually better) by
  supporting/subsidizing private industry. Follow @p{(link}this
  link@p{link)} for a reasonable, very-smart, mostly-libertarian
  perspective on public goods. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0327}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-03 18:25:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2055.msg26512@s{hash}msg26512
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bitcoin contains this magical little piece of code: @p{»»}

  @s{code}

  @p{««} If you try to create more than GetBlockValue coins (50, right now)
  when you get lucky and generate a block, all the other clients will
  reject it. @p{»»}

  @p{««}There are a bunch of other checks to prevent cheating (make sure
  you actually did the work to find a valid hash for the block, make sure
  all the transactions in the block are valid, etc), but that simple
  little piece of code is what restricts the supply. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0328}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-03 19:49:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2060.msg26555@s{hash}msg26555
@section 3 {tx}

  @p{««}I just checked in a minor bug fix / cleanup. @p{»»}

  @p{««}The bug: boolean options/flags were being treated inconsistently.
  If you specified -gen=0, that meant (and still means) "do not generate."
  But specifying -testnet=0 did the opposite of what you might expect.
  @p{»»}

  @p{««}Now all boolean flags behave the same way; for example:

    @p{(li} -gen : means generate @p{li)}

    @p{(li} -gen=1 (or gen=1 in bitcoin.conf): means generate @p{li)}

    @p{(li} -gen=0 (or gen=0 in bitcoin.conf): means do not generate
    @p{li)}

  @p{««}... and if you don't specify the option at all, that means "don't."
  @p{»»}

  @p{««}@p{(bf}Check your bitcoin.conf file!@p{bf)} If you are using
  anything beside "0" and "1" for boolean options, you need to change. I
  had: @p{»»}

   @s{code}

  @p{««} ... in one of my bitcoin.conf files. The correct syntax is
  rpcssl=1 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0329}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-04 16:25:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2070.msg26803@s{hash}msg26803
@section 3 {tx}

  @p{««}I've been lobbying for the mimetype solution. @p{»»}

  @p{««}I did a little mockup a while ago of what happens if you click on a
  link and do NOT have bitcoin installed (which, in my opinion, is the
  most important case): @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0330}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-04 23:10:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2070.msg26896@s{hash}msg26896
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nope, the hard parts aren't parsing the bitcoin: url string (or
  the file), and once parsed the same code could do the actual request.
  @p{»»}

  @s{quotedtext}

  @p{««} The hard part: what happens if I click on a pay-using-bitcoin link
  and I don't happen to have bitcoin running right now? @p{»»}

  @p{««}The browser or OS runs bitcoin and hands it the payment request
  info. @p{»»}

  @p{««}The bitcoin process checks to see if there is already another
  bitcoin process running. @p{»»}

  @p{««}Nope. Ok, load the wallet. And then wait until we're caught up
  fetching the block chain that we missed while we weren't running. Gotta
  do that because some of the transactions in my wallet might have been
  spent (if you copied your wallet somewhere), or you might have received
  payments while bitcoin wasn't running. @p{»»}

  @p{««}And so N minutes after clicking bitcoin is FINALLY ready to send
  payment. If N is greater than 1, then that really sucks! @p{»»}

  @p{««}I like click-to-pay, and I want it to work; it would work well now
  for the "I'm running bitcoin and connected to the network 24/7" use
  case. But I don't think that will be the common use case (most people
  probably won't bother generating). @p{»»}

  @p{««}So I think we've got to figure out some clever way of making
  click-to-pay quick@p{--} maybe ask for payment permission and then have
  bitcoin chug away in the background, popup an alert if there's some
  problem paying, or just shut itself down after it's caught up with the
  block chain and has submitted the payment. Or, assuming you have enough
  coins in your wallet, maybe just throw the transaction onto the network
  and let peers tell you if you're accidentally double-spending (that
  makes me very nervous, though). Or... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0331}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-05 19:24:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2089.msg27098@s{hash}msg27098
@section 3 {tx}

  @p{««}genjix, you're the third person to run into this problem; I'm
  looking into it. @p{»»}

  @p{««}I suspect the problem is running a later svn version and then
  running the same wallet with an earlier svn version; the format of
  wallet transactions changed recently to support the 'accounts' feature.
  @p{»»}

  @p{««}Your bitcoins are still safe in the wallet (all the private keys
  are still in there). Stay tuned... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0332}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-06 00:20:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2089.msg27181@s{hash}msg27181
@section 3 {tx}

  @s{quotedtext}

  @p{««} Peer into my crystal ball with me as we predict the future....
  @p{»»}

  @p{««}No, seriously, upward compatibility (reading old wallet.dat's into
  new versions of bitcoin) shouldn't be an issue. @p{»»}

  @p{««}And Satoshi and I are discussing possible fixes for the
  upgrade/downgrade/upgrade scenario that we think is causing this.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0333}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-06 15:30:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2089.msg27361@s{hash}msg27361
@section 3 {tx}

  @s{quotedtext}

  @p{««} My automatic backup strategy is: @p{»»}

  @p{««}Cron task that runs a shell script twice a day. @p{»»}

  @p{««}The shell script does: @p{brk} call bitcoind backupwallet to create
  a time/date-stamped wallet file @p{brk} gpg encrypt the wallet with my
  public key @p{brk} copy the result to an off-machine backup location
  @p{brk} (I'm using Amazon S3, which is itself redundantly backed up to
  multiple geographic locations automatically) @p{»»}

  @p{««}Shell script looks like: @p{»»}

  @s{code}

  @p{««} I'd suggest doing something similar (replace the s3cmd with an scp
  to copy somewhere if you're not an S3 user; you could even ftp
  somewhere, since the wallet is encrypted it doesn't matter if somebody
  is eavesdropping). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0334}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-06 19:06:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2089.msg27433@s{hash}msg27433
@section 3 {tx}

  @p{««}My private gpg key is kept in my LastPass Vault (as a secure note),
  along with all of my passwords. @p{»»}

  @p{««}I'm a big fan of LastPass; Steve Gibson did a good review of their
  tech and why it's safe on a Security Now podcast a while back. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0335}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 12:40:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2127.msg27733@s{hash}msg27733
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}The getaccountaddress method will return the same address until it
  is used (until a payment is received on that address). @p{»»}

  @p{««}But getnewaddress always creates, stores, and returns a new
  address.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0336}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 13:58:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2129.msg27744@s{hash}msg27744
@section 3 {tx}

  @p{««}I just commited svn r197 (version 0.3.17.05); it is a "prevent
  possible security problems we haven't thought of" fix. @p{»»}

  @p{««}Before this change, you could compile your own version of bitcoin,
  create nonstandard transactions containing extra information or fancy
  new payment features, and all the official bitcoin clients on the
  network would happily include those transactions in the blocks they were
  generating and would relay them to their peers. @p{»»}

  @p{««}After this change, official bitcoin clients will @p{(bf}not@p{bf)}
  relay nonstandard transactions or include them in blocks that they
  create. They will, however, still accept non-standard transactions that
  do manage to get included in a generated block. @p{»»}

  @p{««}So, what should you do if you had a fantastic scheme for doing
  something fabulous with bitcoin that relied on the ability to generate
  nonstandard transactions? @p{»»}

    @p{(li} 1. Implement your fantastic new features. @p{brk} 2. Run it on
  the testnet to test it out. You can pretty easily generate blocks there,
  and, as said above, peers @p{(it}will@p{it)} accept your nonstandard
  transactions in blocks that you generate. @p{brk} 3. Convince the rest
  of us that your idea is great@p{--} or, at least, convince a good
  percentage of the bitcoin-generating nodes that your idea is great.
  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0337}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 14:29:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2129.msg27748@s{hash}msg27748
@section 3 {tx}

  @s{quotedtext}

  @p{««} A transaction that is signed in a way that the standard bitcoin
  client doesn't understand. @p{»»}

  @p{««}For example, there's been some discussion in other threads about
  using OP_DROP to embed extra data in transactions; doing something like
  that would create non-standard transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0338}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 14:39:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2007.msg27752@s{hash}msg27752
@section 3 {tx}

  @p{««}Just to close the loop on this: @p{»»}

  @p{««}This happened when: @p{»»}

    @p{(li}You ran version 0.3.17, and sent/received some coins @p{li)}

    @p{(li}You then ran an earlier version, and the coins you
    sent/received with 0.3.17 were rewriten to the wallet (e.g. you spent
    them or they got included in a block). They'd get rewritten
    incorrectly (marked as version 0.3.17, but missing extra info).
    @p{li)}

    @p{(li}... and then you upgraded to version 0.3.17 again. Bitcoin
    would crash trying to read the extra, missing info. @p{li)}

  @p{««}svn r196 fixes the problem, by storing the extra account info in a
  different way and detecting the badly-written 0.3.17 entries. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0339}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 17:44:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2134.msg27797@s{hash}msg27797
@section 3 {tx}

  @p{««}I'm happy to announce @p{(link}ClearCoin@p{link)}, my bitcoin
  escrow service: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}It makes bitcoin transactions safer by securely holding coins in
  escrow until both buyer and seller are satisfied. @p{»»}

  @p{««}If you are buying something using bitcoins, it makes the
  transaction @p{(bf}much@p{bf)} safer. If you are unsatisfied, you will
  eventually get your bitcoins refunded to you@p{--} you can think of
  ClearCoin as do-it-yourself chargebacks. @p{»»}

  @p{««}If you are selling something using bitcoins, ClearCoin is safer
  than ad-hoc arrangements to reassure reluctant customers (like "I'll
  ship you the product if you promise to pay within 30 days" or "pay me
  half now and half on delivery"). @p{»»}

  @p{««}I'm looking for questions, comments and feedback. You can give it a
  try for free@p{--} transactions of less than 100 bitcoins are free, and
  you can setup an escrow account to yourself just to see how ClearCoin
  works. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0340}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 21:01:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2134.msg27862@s{hash}msg27862
@section 3 {tx}

  @p{««}Thanks for all the great feedback! @p{»»}

  @p{««}Maybe one way to think about ClearCoin is as a tool to help manage
  risk between buyer and seller. @p{»»}

  @p{««}If the buyer completely trusts the seller, then you don't need
  ClearCoin@p{--} just send bitcoins directly. @p{brk} If the seller
  completely trusts the buyer, then just send the product first. @p{»»}

  @p{««}Usually there's some level of trust/mistrust between buyer and
  seller. If you use ClearCoin in creative ways, you should be able to
  come up with a way of using ClearCoin that balances the risks to both
  buyers and sellers. @p{»»}

  @p{««}To take davout's example: The person paying could deposit 20% of
  the funds in a ClearCoin account, then immediately release that 20% as a
  "good faith payment". Then they deposit the other 80%. @p{»»}

  @p{««}That gives an 80/20 risk split. "Half now, half on delivery" type
  arrangements can be done the same way. @p{»»}

  @p{««}davidonpda: You can choose how long your coins will be tied up when
  you create the escrow account@p{--} one month, six months, or a year. Of
  course, the longer they're held the more comfortable the person on the
  other side of the transaction will be. @p{»»}

  @p{««}PS to Vinnie: ClearWing Software is the company; ClearCoin is the
  service. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0341}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-07 21:03:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2134.msg27865@s{hash}msg27865
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, although the first big feature on my ClearCoin TODO list is a
  reputation/feedback system. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0342}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 00:41:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2151.msg28324@s{hash}msg28324
@section 3 {tx}

  @p{««}I'll and add another reason not to have a "list transactions that
  happened after @p{lt}txid@s{gt}" : @p{»»}

  @p{««}move "transactions" don't have a transaction id, but they do affect
  account balances (and are listed in listtransactions). @p{»»}

  @p{««}Your code is going to get really messy if you expect to call
  listtransactions and then squirrel away the txid of the last item
  returned. If it was "category":"move", there WILL be no txid... @p{»»}

  @p{««}RE: eliminating polling: at some point fairly soon, I plan on
  cleaning up my "monitorreceived" patch, to POST to a URL when
  transactions come in or blocks are accepted... but I need to do some
  Deep Thinking to redesign based on lessons learned from 'accounts'. It
  might turn into a very minimal API, where the notification is "Hey, txid
  @p{lt}123ae4221...@s{gt} just got to N confirmations, you might want to
  call gettransaction and getbalance to get up-to-date." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0343}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 00:48:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2162.msg28326@s{hash}msg28326
@section 3 {tx}

  @s{quotedtext}

  @p{««} There's been exactly one block with non-standard transactions:
  @p{»»}

    @p{(li}@s{(link)} @p{li)} ... and it contained no fees. @p{»»}

  @p{««}HOWEVER: jgarzik, you're over-reacting, too. This will
  @p{(bf}not@p{bf)} cause a block chain split; all clients will accept
  blocks containing non-standard transactions as valid. Most (many?) just
  won't put non-standard transactions in blocks that they generate, and
  won't relay them. There will be no havoc.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0344}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 14:51:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2162.msg28539@s{hash}msg28539
@section 3 {tx}

  @s{quotedtext}

  @p{««} Several months ago, around the time when the 0.3.9 bugs were
  found, I privately told Satoshi that I thought whitelisting acceptable
  transaction types was a better way to go, rather than blacklisting
  transaction types that we find out cause problems. @p{»»}

  @p{««}The danger is similar websites that try to blacklist
  @p{lt}script@s{gt} tags in HTML entered by users to prevent
  cross-site-scripting hacks. See @s{(link)} for a nice sampling of how
  creative hackers can be. @p{»»}

  @p{««}I haven't asked Satoshi if the recent discussion of BitDNS putting
  extra data in the block chain swayed his opinion or if he woke up in the
  middle of the night and realized that a creative use of OP_SOMETHING
  might lead to an exploit. I don't think it matters; I'm still convinced
  that whitelisting acceptable transaction types is the right thing to do.
  @p{»»}

  @p{««}As for "the above option was thrown out by the developers" @p{--}
  @p{(bf}nothing@p{bf)} has been thrown out! Again, I haven't talked to
  Satoshi, but I'm open to the idea of a third 'standard' transaction type
  that includes extra, arbitrary data. Lets have that discussion,
  implement it on the -testnet, poke at it, try to imagine all the
  possible ways it can be misused, try to estimate the benefits and
  costs... and if there's general consensus that it is a good idea, roll
  it into production. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0345}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 16:01:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2163.msg28568@s{hash}msg28568
@section 3 {tx}

  @s{quotedtext}

  @p{««} Quick reaction: what stops malicious or lazy BitX chain generator
  from implementing a type of denial-of-service attack against some
  bit-app they either don't like or don't know about? If BitX blocks are
  never rejected for bit-app reasons, then what is the incentive for
  main-BitX chain generators to include only (or any!) valid bit-app
  hashes? What stops me from constantly flooding the BitX network with
  bogus bit-app hashes and asking them to be included in BitX blocks?
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0346}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 16:14:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2170.msg28575@s{hash}msg28575
@section 3 {tx}

  @p{««}Can you change the username/password in the authentication and then
  have it POST to: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... so I can see all the headers/etc ? You're probably not sending
  what you think you're sending... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0347}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 16:43:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=644.msg28593@s{hash}msg28593
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nightly builds are a great idea; does the build service do an
  automatic svn update? Anybody else willing to help get GUI-bitcoin
  building (or anybody know somebody on the wxWidgets team?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0348}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 16:51:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2170.msg28601@s{hash}msg28601
@section 3 {tx}

  @p{««}You're missing a blank line between the HTML headers and the HTML
  body@p{--} PostBin and Bitcoin both think you're sending an empty
  request. @p{»»}

  @p{««}I dunno enough about JayRock to suggest how to fix that... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0349}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 16:53:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2170.msg28606@s{hash}msg28606
@section 3 {tx}

  @p{««}Actually, thinking about it, are you sending \r\n for newlines?
  @p{»»}

  @p{««}Fricking PC versus Unix versus Mac line-endings will be causing
  problems until the end of time.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0350}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-09 19:41:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2151.msg28666@s{hash}msg28666
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, listtransactions "*" @p{lt}count@s{gt} is possible. The other
  account routines could return a new "invalid account name" error if
  given "*". @p{»»}

  @p{««}I've got two issues with it, though: @p{»»}

    @p{(li} 1. listtransactions "*" will have to iterate over every
    transaction in the wallet (transactions are not indexed by time),
    which will be slow for large wallets and will get slower over time.
    And indexing transactions just so that listtransactions * is fast
    violates the "an optional feature shouldn't cost anything if it is not
    used" principle. @p{li)}

    @p{(li} 2. What is the use case for "list the last N transactions
    across all accounts" ? The only one I can come up with is developing
    an alternate GUI that communicates with bitcoind via the JSON-RPC, but
    to support that at least a couple of other features would have to be
    added at the same time (e.g. listtransactions would needs to add
    account and bitcoin address information to the objects it returns....)
    @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0351}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-10 12:49:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg28848@s{hash}msg28848
@section 3 {tx}

  @s{quotedtext}

  @p{««} moves do not touch the block chain, they add accounting entries to
  your wallet to adjust the balances of the accounts involved. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0352}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-10 12:57:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2170.msg28849@s{hash}msg28849
@section 3 {tx}

  @s{quotedtext}

  @p{««}You just did raise this as a potential bug, but you need to
  convince me that Bitcoin is not following the @p{(link}HTTP/1.1
  spec@p{link)}, which says: @p{»»}

  @s{quotedtext}

  @p{««} ... and, for 'tolerant' applications: @p{»»}

  @s{quotedtext}

  @p{««} What character(s) is JayRock putting between the headers and the
  body? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0353}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-10 13:40:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg28858@s{hash}msg28858
@section 3 {tx}

  @s{quotedtext}

  @p{««} Accounts do not affect the previous-transaction-selection
  algorithm at all; if you sendfrom FOO, bitcoin doesn't make any effort
  to only use coins that were received by FOO. @p{»»}

  @p{««}Think of your wallet as being a big pool of coins. Coins are not
  stamped with account names when they go in, instead, there's a little
  man with a green visor making entries in a ledger. @p{»»}

  @p{««}Each receiving address is a pipe that dumps coins into the pool,
  and the little man knows which pipes are assigned to each account. @p{»»}

  @p{««}Every send the little man grabs his shovel and picks a bunch of
  coins randomly from the pool. Then debits an account. @p{»»}

  @p{««}And for moves, the little man doesn't have to touch the coins in
  the pool at all, he just adjusts his ledger. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0354}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-10 17:31:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2170.msg28919@s{hash}msg28919
@section 3 {tx}

  @p{««}Sorry to send you on a wild goose chase, the problem is
  @p{(bf}NOT@p{bf)} CRLF issues. @p{»»}

  @p{««}The problem is in your HTTP headers; you're sending the request as:
  @p{»»}

  @p{««}Content-Type: application/x-www-form-urlencoded @p{»»}

  @p{««}The correct Content-Type for @p{(link}JSON-RPC over HTTP@p{link)}
  is: @p{»»}

    @p{(li}Content-Type SHOULD be 'application/json-rpc' but MAY be
    'application/json' or 'application/jsonrequest' @p{li)}

  @p{««}I'm not sure what .net is doing with the body of the request, but
  by the time it gets to Bitcoin/PostBin, it has x-www-form-urlencoded it
  enough to confuse the heck out of them. @p{»»}

  @p{««}When you get this working, please update this thread, and for extra
  positive karma, add a .net section to the @p{(link}Bitcoin
  JSON-RPC@p{link)} wiki page. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0355}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-11 04:09:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg29080@s{hash}msg29080
@section 3 {tx}

  @p{««}I wrote all this up (minus the little man) for the wiki: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Let me know if it doesn't make sense. Or, even better, fix it for
  me! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0356}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-11 04:15:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1886.msg29082@s{hash}msg29082
@section 3 {tx}

  @p{««}Oh, and RE: privacy: @p{»»}

  @p{««}Mixing all of the 'coins' for all of the accounts together is, I
  think, an overall plus for privacy. True, you might receive coins from
  somebody and be able to figure out "Hey, they sent me some of exactly
  the same coins I deposited in my BigBitBank account yesterday! They must
  have an account at BigBitBank, too!" @p{»»}

  @p{««}But mixing all the accounts' coins together makes it
  @p{(bf}much@p{bf)} more difficult to figure out where any user's coins
  came from, or, if you know where they came from, where the user is
  spending their bitcoins. Unless you can subpeona BigBitBank's records,
  of course... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0357}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-11 20:51:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=483.msg29238@s{hash}msg29238
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm not the designer of Bitcoin (I am one of the developers), but
  I @p{(bf}have@p{bf)} been thinking a lot about what it will take to make
  it safe(r) for my grandma to use. @p{»»}

  @p{««}playanaut, I'd love to hear your suggestions on how to make bitcoin
  better. And (shameless plug): I'd also love to know if you think my
  latest project, @p{(link}ClearCoin@p{link)}, is a step in the right
  direction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0358}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-12 17:18:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2226.msg29472@s{hash}msg29472
@section 3 {tx}

  @p{««}I was sent this question in email: @p{»»}

  @p{««}@p{(bf}Why can't somebody just create a version of the software
  that gives you extra bitcoins?@p{bf)} @p{»»}

  @p{««}... and couldn't find a good, non-geeky answer in the FAQs. So
  @p{(link}I wrote one@p{link)}: @p{»»}

  @p{««}When you spend some bitcoins, the software on your machine has to
  prove to the software running on everybody else's machine that those
  bitcoins are valid. @p{»»}

  @p{««}How does it do that? Well, it is a little bit complicated; you've
  got to understand how bitcoins are created, and how they are traded.
  @p{»»}

  @p{««}First, how they're created: 50 bitcoins are created approximately
  every 10 minutes. Everybody who is trying to create bitcoins is in a
  race to try to find those 50 bitcoins; they are really hard to find,
  but, once found, it is easy to verify that, yes, indeed, your bitcoin
  software found them, so you get to spend them. @p{»»}

  @p{««}Second, how they're traded: Imagine you did find 50 bitcoins (well,
  your computer found them by running the bitcoin software for a few
  months or a year@p{--} they are not easy to find, and are harder to find
  the more people who are looking for them). You trade them to me by
  sending them to my bitcoin address. Inside the software, a messages is
  created and then broadcast to everybody that says "These 50 bitcoins
  that we all agree are valid are hereby officially traded to somebody
  else (me@p{--} well, one of my bitcoin receiving addresses, actually)."
  @p{»»}

  @p{««}Now I've got them. If you try to trade those same 50 bitcoins to
  somebody else, it won't work@p{--} everybody running Bitcoin sees all the
  trades, so if you try to spend the same coins a second time everybody
  else's software will reject your attempt to cheat. @p{»»}

  @p{««}And that's it@p{--} that's how it works. Bitcoins are scarce because
  only about 50 are created every ten minutes. And you can't claim to have
  more than you really have because everybody else can check to see if
  your coins really were created by the "race" process, or if they
  were from valid trades.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0359}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-12 21:36:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2211.msg29525@s{hash}msg29525
@section 3 {tx}

  @p{««}@p{(link}This thread@p{link)} talks in detail about Bitcoin's use
  of hashing of ECDSA public keys to generate bitcoin addresses. @p{»»}

  @p{««}Executive summary: @p{»»}

    @s{code}

  @p{««}So you'd need to break both RIPEMD-160 and SHA-256 hashing
  algorithms. And the RIPEMD break would have to be quite extreme@p{--}
  more than just "add some random data to force a hash collision" (which
  is how MD5 is broken), because it is hashing a SHA-256 hash, so you're
  not able to add some random data to be hashed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0360}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-12 21:44:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1796.msg29533@s{hash}msg29533
@section 3 {tx}

  @s{quotedtext}

  @p{««}Change "getnewaddress(label)" to "getaccountaddress(label)" and
  you'll get the same address over and over, until somebody donates. Then
  you'll get a different one. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0361}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-12 21:54:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2152.msg29535@s{hash}msg29535
@section 3 {tx}

  @s{quotedtext}

  @p{««} getaccountaddress is designed for exactly this kind of thing@p{--}
  it will return the same address over and over, until it gets used (until
  somebody donates). After that, it returns a different address... @p{»»}

  @p{««}Of course, if "the public" is grabbing the donation address off
  your "Donate to Us" page, they could generate a list of donation
  addresses, add up the donations received on all those addresses, and
  figure it out. Depending on how many donations you're getting that might
  be easy (scrape the page once per day) or hard (if you're getting dozens
  of donations per day). @p{»»}

  @p{««}You could make it much harder for anybody to figure out how much
  you're getting in donations by randomly donating to yourself (using the
  same address returned by getaccountaddress), preferably from a wallet
  shared by lots of other people (like a MyBitcoin or Mt.Gox account)...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0362}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-12 22:44:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2211.msg29555@s{hash}msg29555
@section 3 {tx}

  @s{quotedtext}

  @p{««} If the hashing algorithms are broken I might be able to generate
  an ECDSA private/public key pair where the public key hashes to the same
  bitcoin address as one of your public keys. @p{»»}

  @p{««}If I can do that, then I can spend your coins. @p{»»}

  @p{««}On my list of things to worry about, this is just below "Asteroid
  impact destroys the earth" (but above "Aliens invade and make me their
  slave"). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0363}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-13 17:10:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2245.msg29804@s{hash}msg29804
@section 3 {tx}

  @s{quotedtext}

  @p{««} What theymos said. You're asking for the balance of the
  @p{(it}account@p{it)} named '1Fs5rqB2sXZ3kax1r3HfuYpK2ksSxLYJT8', and
  there is no such account. @p{»»}

  @p{««}Whether bitcoin should return an error (instead of 0) if you ask
  for the balance of a non-existant account is debatable... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0364}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-14 14:28:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2227.msg30073@s{hash}msg30073
@section 3 {tx}

  @s{quotedtext}

  @p{««} Did you simulate network connectivity at all? Bitcoin is a
  semi-randomly connected network, where most of the connections are (I
  would guess) outbound connections from non-generating nodes who are
  sitting behind firewalls. With a typical node having 8 random
  connections, to different /16 networks, it seems to me it would be
  pretty tough to get tight-enough control over enough network connections
  to consistently win the "announce a new block" race. @p{»»}

  @p{««}Anybody know how to estimate what percentage of connections the
  cartel would have to control to only lose the announce-a-block race 15%
  of the time? It'll be way more than 15%.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0365}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-14 15:53:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2227.msg30094@s{hash}msg30094
@section 3 {tx}

  @s{quotedtext}

  @p{««} There is something wrong with your simulation. Proof: @p{»»}

  @p{««}Imagine a bitcoin world with two Cartels, each with 50% of the
  power, each following the strategy you outline. @p{»»}

  @p{««}It is obvious that they cannot BOTH get 59% of the blocks.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0366}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-14 16:37:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2227.msg30108@s{hash}msg30108
@section 3 {tx}

  @p{««}If you're simulating, be sure you're not overlooking the
  'opportunity cost' of working on the next-valid-block when you're
  'holding back' blocks. @p{»»}

  @p{««}Example: @p{»»}

  @p{««}Cartel finds block N. Instead of releasing it right away, Cartel
  holds it and starts working on block N+1 (trying to get a head start).
  @p{»»}

  @p{««}Before Cartel finds block N+1, somebody else finds an alternate
  block N and announces it. @p{»»}

  @p{««}IF Cartel loses the race to announce, then Cartel has wasted time
  looking for a block N+1 that will not be accepted. @p{»»}

  @p{««}If they simply announce block N right away, they'll never waste
  time trying to find a block N+1 that has only a 50% chance of being
  accepted. @p{»»}

  @p{««}Unless the Cartel can propagate their blocks across the network
  faster than the whole rest of the network, there is never an advantage
  to holding back blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0367}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-14 17:01:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2265.msg30114@s{hash}msg30114
@section 3 {tx}

  @s{quotedtext}

  @p{««} Simplest way: @p{»»}

  @p{««}Call getaccountaddress "charity_name" when you generate the web
  page. You'll get the same address over and over, until somebody donates.
  Then you'll get a new address. @p{»»}

  @p{««}Then periodically call: @p{»»}

    @p{(li}getbalance "charity_name" @p{li)} ... and if the balance is
  greater than zero, call: @p{»»}

    @p{(li}sendfrom "charity_name" charity_real_bitcoin_address amount
    @p{li)}

  @p{««}... to send the charity the accumulated coins. @p{»»}

  @p{««}If you deal with several charities this way, AND you're bundling up
  several donations before forwarding the coins to the charity, then it'll
  be hard to connect donors to particular charities. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0368}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-14 20:42:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2227.msg30181@s{hash}msg30181
@section 3 {tx}

  @s{quotedtext}

  @p{««} I deleted two posts@p{--} one from you that was a quote of
  ByteCoin's simulation results (and nothing else). @p{»»}

  @p{««}And a second from ByteCoin (if I recall correctly), saying
  essentially "what's up with the empty post?" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0369}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-15 17:40:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2294.msg30424@s{hash}msg30424
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, implementing it would be easy. Implement it (don't forget the
  UI), test it on the test network (where it is pretty trivial to get
  non-IsStandard stuff into blocks), and then lobby for a new 'standard'
  transaction type. @p{»»}

  @p{««}theymos, please stop acting like the current IsStandard test is set
  in stone. It is not, and, as Satoshi said, new versions of the client
  are rapidly adopted by a majority of the network, so introducing a new
  transaction type will not be a big deal. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0370}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-15 21:59:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=347.msg30484@s{hash}msg30484
@section 3 {tx}

  @p{««}@s{image} @p{»»}

  @p{««}A big spike 18 hours ago, but then back to pretty much normal.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0371}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 01:22:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2306.msg30540@s{hash}msg30540
@section 3 {tx}

  @p{««}I just committed svn rev 103. Changes are: @p{»»}

  @p{««}listaccounts : lists all the accounts in your wallet along with
  their current balances. @p{»»}

  @p{««}listtransactions : call it with no arguments, or give it '*' as the
  account name, and it lists the last N (default 10, as before)
  transactions from all accounts. Part of this change is disallowing '*'
  as an account name. @p{»»}

  @p{««}-rpctimeout : Thanks to Mt'AwAy who pointed out that, if somebody
  was allowed to connect to the bitcoin rpc port (via -rpcallowip), then
  they could connect, do nothing, and hang the connection, causing a
  denial-of-RPC-service. Now bitcoin's RPC thread will close the
  connection if it doesn't get the HTTP request within -rpctimeout
  (default 30) seconds. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0372}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 13:53:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2316.msg30741@s{hash}msg30741
@section 3 {tx}

  @p{««}move @p{lt}fromaccount@s{gt} @p{lt}toaccount@s{gt}
  @p{lt}amount@s{gt} (minconf=1) (comment) @p{»»}

  @p{««}minconf does what you want (gives an Account has insufficient funds
  error if not enough funds with minconf confirmations). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0373}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 14:33:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2314.msg30750@s{hash}msg30750
@section 3 {tx}

  @p{««}Outputting the transaction time would be easy. @p{»»}

  @p{««}"The address that received funds" is not as obvious as you might
  think. It is possible to generate transactions that are split and go to
  several addresses (well, it is possible if you use your own custom
  client, standard Bitcoin doesn't expose that feature). @p{»»}

  @p{««}Some or all of those addresses might be yours, and might be
  associated with any number of accounts. @p{»»}

  @p{««}I see two possible ways of dealing with this: @p{»»}

    @p{(li} 1. Generate multiple entries for a single transaction. E.g. if
    you receive a split transactions, where 50 BTC goes to address
    '1aaa...' and 10 to address '1bbbb...', listtransactions will list
    that as two separate entries that share the same txid: @p{li)}

  @s{code}

  @p{««} You can already get two separate entries for one transaction if
  you send to yourself, so this might be the best answer. And it makes the
  common case simpler. @p{»»}

    @p{(li} 2. Or maybe 'toaddress' should be address:amount pairs, like
    this: @p{li)}

  @s{code}

  @p{««} Writing all this down, I'm thinking that listtransactions aught to
  generate multiple entries, but gettransaction aught to generate
  address:amount pairs (and still omit category/account, as it does now).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0374}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 14:44:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2313.msg30753@s{hash}msg30753
@section 3 {tx}

  @p{««}Do you have gen=something in your bitcoin.conf? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0375}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 16:29:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2314.msg30776@s{hash}msg30776
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, only the amount sent to the address associated with the web
  app's account(s) will be reported in listtransactions. @p{»»}

  @p{««}But that's exactly why this is a lot harder than it seems@p{--}
  we've got to think about weird transactions people might use to try to
  break websites that use this API. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0376}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 17:46:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2314.msg30804@s{hash}msg30804
@section 3 {tx}

  @s{quotedtext}

  @p{««} Just use transactionID+account. @p{»»}

  @p{««}You've already got the problem that if a customer sends coins from
  account A to an address that belongs to account B, that is a single,
  unique transaction that affects two accounts. @p{»»}

  @p{««}listtransactions will Do the Right Thing (generate two entries,
  different accounts, same transaction id). And gettransaction won't lie
  to you (it doesn't say anything about what accounts were involved, on
  purpose, for exactly this reason). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0377}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 18:24:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2306.msg30819@s{hash}msg30819
@section 3 {tx}

  @p{««}... and I just noticed an egregious bug: listtransactions was
  reporting the receiving address instead of the account name for
  "receive" transactions. Fix is svn rev 104. Please bang on it and let me
  know if I screwed anything else up. @p{»»}

  @p{««}While I was committing, I also added "time" to transaction info
  output, and fixed a little bug reported a while ago (setgenerate true 0
  is now the same as setgenerate false). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0378}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-16 23:42:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2313.msg30901@s{hash}msg30901
@section 3 {tx}

  @p{««}Weird. Are you on Linux or Mac? If you are, grab my
  @p{(link}bitcointools@p{link)} and run @p{»»}

    @p{(li}./dbdump.py @p{--}wallet @p{li)}

  @p{««}... then look for: @p{»»}

  @p{««}nLimitProcessors: @p{»»}

    @p{(li}and @p{li)} fGenerateBitcoins: @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0379}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-17 17:11:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2328.msg31143@s{hash}msg31143
@section 3 {tx}

  @p{««}Works nicely on Linux, and is the recommended way to close dialogs.
  @p{»»}

  @p{««}Anybody able to give it a quick compile and test on Windows? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0380}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-18 16:27:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2343.msg31365@s{hash}msg31365
@section 3 {tx}

  @p{««}We're pretty close to being able to duplicate the bitcoin GUI using
  the RPC. @p{»»}

  @p{««}I think the only thing missing is reporting bitcoin addresses in
  listtransactions. That gets a little sticky with multisends (one
  transactions that sends coins to multiple recipients); here's what I'm
  thinking of implementing after doing some brainstorming with
  theymos/jgarzik/nanotube in IRC chat and running a couple of 'multisend'
  tests on the test network: @p{»»}

  @p{««} Code: "category" : "receive", @p{brk} "amount" : amount, @p{brk}
  "address" : "bitcoinaddress" ... plus the rest of what is reported now
  @p{brk} (account/txid/confirmations/time/comment). That's the "received
  on" @p{brk} address, of course. @p{»»}

  @p{««}On the send side, I'm leaning towards: @p{»»}

  @p{««}Code: @s{code} for a multisend. ... plus the
  rest of what is reported now @p{brk}
  (account/txid/confirmations/time/comment). @p{»»}

  @p{««}I don't like that the common case looks kind of ugly; I'd much
  prefer @p{brk} just Code: "address" : "bitcoinaddress" @p{brk} That
  could be done by having listtransactions report multiple category:send
  entries for a multisend... except it is not obvious @p{brk} which one
  should report the fee, if there is a fee. First one? All of them? @p{»»}

  @p{««}I'm also a worried that websites might get their accounting wrong
  if they're not prepared to deal with multisends; making "toaddress" an
  @p{brk} Object makes it obvious that multisends are possible. The only
  way a website would get a multisend would be if they allow users to
  import keys from their local bitcoin wallet, which nobody is doing...
  yet. @p{»»}

  @p{««} Here's how listtransactions currently reports a complex multisend:
  @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0381}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-18 20:19:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2334.msg31418@s{hash}msg31418
@section 3 {tx}

  @s{quotedtext}

  @p{««}Short answer: you don't have to worry about it. @p{»»}

  @p{««}Long answer: if you @p{(bf}want@p{bf)} to worry about being as
  network-bandwidth-efficient as possible, run one node normally, and run
  all the rest with the -noirc -connect=IP.AD.DR.SS flags so they connect
  only to the one 'master' node. All the network traffic will then go
  through the master node. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0382}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 02:19:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2343.msg31522@s{hash}msg31522
@section 3 {tx}

  @s{quotedtext}

  @p{««} move is its own category (and may be + or -, never has a txid or
  fees). And the output I pasted is what listtransactions does right now
  (it doesn't report bitcoin addresses). @p{»»}

  @p{««}After some private feedback, I'm now leaning towards
  listtransactions giving multiple category:send entries (with the same
  txid) for the multisend case. That matches what is done for the
  category:receive end. transaction fee... I think I'll do what is easiest
  to implement which is repeat it in all of them. @p{»»}

  @p{««}So the example would look like this, with three receives and three
  sends: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0383}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 03:23:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2321.msg31535@s{hash}msg31535
@section 3 {tx}

  @p{««}Feel free to take anything I've written here on the forums or on
  the wiki and do whatever you like with it. @p{»»}

  @p{««}And, for what it is worth, I like the new wiki more than the old
  wiki; the new one is prettier and more powerful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0384}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 16:13:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2364.msg31642@s{hash}msg31642
@section 3 {tx}

  @p{««}I've created an 'official' Bitcoin bug/issue/feature request
  tracking system at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The github issues system has a simple voting system; lets use it!
  @p{»»}

  @p{««}And if you see an issue that you want to work on, use the
  commenting system to let everybody know you're working on it. I'd like
  to be open about who is working on what, and what features/bugs/issues
  people think are important. @p{»»}

  @p{««}However... we'll still be very conservative about what changes make
  it into the official bitcoin client. Bitcoin will be destroyed if people
  using it lose their trust in it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0385}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 16:30:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2364.msg31647@s{hash}msg31647
@section 3 {tx}

  @s{quotedtext}

  @p{««} Umm... there will be no Top Bureaucrat counting votes and telling
  people what to do. There will still be plenty of anarchy, I promise!
  @p{»»}

  @p{««}Use the voting system to express what is important to YOU. @p{»»}

  @p{««}Or not. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0386}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 16:41:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2367.msg31651@s{hash}msg31651
@section 3 {tx}

  @p{««}With Satoshi's blessing, and with great reluctance, I'm going to
  start doing more active project management for bitcoin. @p{»»}

  @p{««}Everybody please be patient with me; I've had a lot of project
  management experience at startups, but this is the first open source
  project of any size I've been involved with. Anyway, I've created an
  integration/staging tree at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and am proposing this for a development process: @p{»»}

  @p{««}Straw-man plan for Bitcoin development (open source vets, please
  slap me around and help make this better): @p{»»}

  @p{««}Developers work in their own trees, then submit pull requests when
  they think their feature is ready. @p{»»}

  @p{««}Requests get discussed (where? here in the bitcoin forums?) and if
  there's broad consensus they're a good thing, well written, match coding
  style, etc. then they're merged into the 'master' branch. @p{»»}

  @p{««}master branch is regularly built and tested (by who? need people
  willing to be quality assurance testers), and periodically pushed to the
  subversion repo to become the official, stable, released bitcoin. @p{»»}

  @p{««}We'll create feature branches if/when there are major new features
  being worked on by several people. @p{»»}

  @p{««}Discussion, feedback, etc, @p{(bf}especially@p{bf)} from people
  with experience leading or working on other open source projects, is
  very welcome.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0387}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-19 17:16:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2365.msg31661@s{hash}msg31661
@section 3 {tx}

  @s{quotedtext}

  @p{««}When that happens, I think most people using bitcoin will not be
  running always-connected-to-the-bitcoin-network software. I think there
  will be at least three different sets of people: @p{»»}

    @p{(li} 1. People who trust a web site to keep their wallet safe more
    than they trust themselves. They'll use sites like MyBitcoin or MtGox,
    which give them an online wallet. @p{li)}

    @p{(li} 2. People who don't or won't trust anybody to keep their
    wallets safe, but don't have a high-speed, always-on Internet
    connection. They will use a 'payment gateway', where they submit
    transactions that are signed by their own computer (they don't have to
    trust the payment gateway to keep their wallet, the gateway just
    forwards relevant transactions onto the bitcoin network for the user).
    @p{li)}

  @p{««}This doesn't exist yet, but writing the code to support this isn't
  terribly hard. @p{»»}

    @p{(li} 3. People who DO have always-on high-speed network
  connections; they'll run bitcoin just like they do today. But, assuming
  the volume @p{brk} of bitcoin transactions continues to increase faster
  than the cost of network bandwidth declines, that will become
  increasingly expensive, @p{brk} so I think more and more users will
  choose option 1 or 2. @p{li)}

  @s{quotedtext}

  @p{««} The current bitcoin doesn't keep all transactions in memory at
  once@p{--} the blkindex.dat and blk0001.dat files in your bitcoin data
  directory stores them on disk.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0388}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-20 14:07:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2373.msg31966@s{hash}msg31966
@section 3 {tx}

  @p{««}I like this feature request; I think it will enable even more
  interesting uses of bitcoin. I created a feature request at github for
  it. @p{»»}

  @p{««}Example: a store that accepts bitcoins could verify that a customer
  sending in a question about some transaction actually IS the same person
  who sent them the bitcoins, by asking the customer to sign their message
  using one of the same bitcoin addresses they used to sign the coins.
  @p{»»}

  @p{««}If the "store" is a privacy-focused VPS provider and the question
  is "Hey, I lost the root password to the virtual server, could you
  generate a new one and encrypt it with this gpg public key", then tying
  that message to a bitcoin transactions is extremely useful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0389}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-20 14:13:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2373.msg31968@s{hash}msg31968
@section 3 {tx}

  @p{««}Oh, and RE: extracting private keys from the wallet: @p{»»}

  @p{««}I'm less excited about that idea. What if the private keys are
  stored in a tamper-proof "trusted security module" hardware doo-hickey,
  and are impossible to export? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0390}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-20 14:23:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2350.msg31971@s{hash}msg31971
@section 3 {tx}

  @s{quotedtext}

  @p{««} Well said! @p{»»}

  @p{««}Trust is Bitcoin's biggest barrier to success. I don't think there
  is anything we can do to speed up the process of getting people to trust
  that bitcoin is solid; it takes time to build trust. However, there is
  @p{(bf}plenty@p{bf)} we could do to lose that trust, including
  overpromising or misrepresenting what bitcoin can do. @p{»»}

  @p{««}Bitcoin is beta software; nobody should trust it 100%. Do not
  invest your life savings in bitcoin@p{--} in fact, do not invest any
  money you're not willing to lose. Expect more ponzi schemes and fraud.
  Expect irrational valuation bubbles, and, while the bitcoin economy is
  small, expect people to try to manipulate the bitcoin markets. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0391}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-20 14:39:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2371.msg31977@s{hash}msg31977
@section 3 {tx}

  @p{««}I'm with Hal@p{--} do we really need another special-case switch?
  Are there significant costs to just always printing when pow fails?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0392}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-20 15:49:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2328.msg32000@s{hash}msg32000
@section 3 {tx}

  @p{««}Anybody have a chance to compile/test this on Windows? @p{»»}

  @p{««}I created an Official Pull Request for this, which I will accept
  and apply unless I hear objections today: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0393}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-21 01:35:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2388.msg32148@s{hash}msg32148
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm working on that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0394}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-21 18:56:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2371.msg32323@s{hash}msg32323
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's what I meant when I asked "are there significant costs?"
  @p{»»}

  @p{««}If one of the mining pool folks think this would be useful in a
  production miner, then I see the value. If it is only really useful if
  you're trying to debug a remote miner that isn't working quite right...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0395}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-21 18:58:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg32326@s{hash}msg32326
@section 3 {tx}

  @p{««} @s{(link)} @p{»»}

  @p{««}Three changes to listtransactions: @p{»»}

  @p{««}Add address to listtransactions output. @p{»»}

  @p{««}"multisends" (non-standard, use one transaction to send to multiple
  addresses) generate N "category":"send" lines. @p{»»}

  @p{««}Bug fix: listtransactions wasn't reporting pay-by-IP-connection
  receive transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0396}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-21 20:07:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg32347@s{hash}msg32347
@section 3 {tx}

  @p{««}Normal send; this one was: @p{»»}

  @s{code}

  @p{««} Again, multi-sends are non-standard transactions. And no, I won't
  give you the hacked code I wrote to generate multisend test cases...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0397}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-22 14:09:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151.msg32491@s{hash}msg32491
@section 3 {tx}

  @s{quotedtext}

  @p{««} Thanks! @p{»»}

  @p{««}Can somebody volunteer to be "translation pull person" for the new
  git integration repository? The job would be packaging up changes into
  "pull requests" (if the person doing the work can't or won't use git),
  giving them a sanity test, and then pulling them into the integration
  repository. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0398}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-22 14:17:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2407.msg32493@s{hash}msg32493
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, that is exactly what the blkindex.dat file is. @p{»»}

  @p{««}wallet.dat contains "extended dance mix" versions of all the
  transactions you care about (all of "your" receives/sends). Those are
  loaded into memory at startup (and then kept up-to-date as new
  transactions are seen), so calculating "your" balance is quick (just
  scan through all wallet transactions in memory and total them up). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0399}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-23 04:17:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg32614@s{hash}msg32614
@section 3 {tx}

  @s{quotedtext}

  @p{««} They won't be different@p{--} you will get two entries that are
  identical. @p{»»}

  @p{««}Bitcoin will sum them up for you if you use the getbalance or
  getreceivedby* RPC commands.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0400}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-23 04:27:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg32616@s{hash}msg32616
@section 3 {tx}

  @s{quotedtext}

  @p{««} I thought bitcoinex was asking about the weird multisend case,
  where there is one Transaction (so one txid), but two or more TxOuts
  with the same amount to the same address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0401}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-23 13:52:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg32713@s{hash}msg32713
@section 3 {tx}

  @s{quotedtext}

  @p{««} If you expect a one-to-one relationship between transactions and
  bitcoin addresses, then yes, a multisend will be a problem for you.
  @p{»»}

  @p{««}If I were implementing the anonymous fund-with-a-bitcoin-address
  system, I would do something like: @p{»»}

  @p{««}Customer "Ed" gives a "send winnings to address"@p{--} lets say it
  just happens to be 1Ed.... @p{brk} Casino gives a funding address @p{--}
  lets call that address 1fundEd... @p{»»}

  @p{««}Casino creates an account named "1Ed..." and associates it with
  address 1fundEd. @p{brk} So any coins Ed sends to 1fundEd.... go into
  the 1Ed... account. @p{»»}

  @p{««}When Ed wants to place a bet, casino checks to see if he has money:
  getbalance 1Ed.... @p{brk} If he does, he can place a bet. @p{brk} If he
  wins, casino sends money: @p{»»}

    @p{(li}move BANK 1Ed... @p{lt}amount Ed won above his bet@s{gt}
    @p{li)}

    @p{(li}sendfrom 1Ed... 1Ed.... @p{lt}amount Ed won@s{gt} @s{hash} Account
  name and cash-out address are the same. @p{li)} If he loses: @p{»»}

    @p{(li}move 1Ed... BANK @p{lt}amount Ed lost@s{gt} @p{li)}

  @p{««}listtransactions is for showing Ed a detailed list of what happened
  to his account. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0402}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-24 16:03:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2434.msg32974@s{hash}msg32974
@section 3 {tx}

  @s{quotedtext}

  @p{««} TIPS (Treasury Inflation Protected Securities), which are sold by
  treasurydirect, compensate for inflation. They are a good place to put
  money that you're pretty sure you will need "soon" @p{--} within the
  next 5 years or so. Assuming you trust the US government not to default
  on its debt (I do@p{--} I think the government might try to inflate away
  the debt, but won't outright default). @p{»»}

  @p{««}Money you won't need soon aught to be invested in something
  productive@p{--} invest in some business or person that is making our
  lives more efficient or pleasant. That should give you the best
  long-term return and will make the world a better place, too. Stock
  market index funds are an inexpensive, mostly safe, mostly
  inflation-proof way to invest. @p{»»}

  @p{««}If you have some 'playing around' money that you can afford to
  lose, you might want to invest in Bitcoins. But bitcoin is a startup
  currency, and should be treated like a high-tech startup company@p{--}
  high-risk, but very high potential reward. You might lose your entire
  investment or it might turn out to be the best investment you ever
  made.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0403}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-27 19:56:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2476.msg33467@s{hash}msg33467
@section 3 {tx}

  @p{««}Can we brainstorm positive emotional arguments? Maybe: @p{»»}

  @p{(li}* Get back at the bankers and megacorporations that robbed us blind
  and drove the economy over a cliff! @p{li)}

  @p{(li}* Bitcoin is The People's Money@p{--} created by YOU, controlled by
  YOU. @p{li)}

  @p{(li}* Use bitcoin and tell (PayPal/your credit card company/the foreign
  currency exchanger) you're tired of paying outrageous fees just to send
  YOUR money to somebody else. @p{li)}

  @p{««}More? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0404}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 20:12:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2507.msg34109@s{hash}msg34109
@section 3 {tx}

  @s{quotedtext}

  @p{««} It dumps out keys in abbreviated hex (I worry about naive users
  accidently publishing screen snapshots showing their full private keys).
  @p{»»}

  @p{««}Teaching bitcointools to dump out keys in OpenSSL ascii-armored
  format is a great idea. It is just not high on my personal priority list
  right now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0405}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 20:21:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1328.msg34115@s{hash}msg34115
@section 3 {tx}

  @s{quotedtext}

  @p{««} You need a service that will let you send multiple, random-looking
  amounts at different times, and then, some time later, send an amount to
  the destination. And then refunds any extra you sent (and you should
  send extra). And if you're really paranoid, it should allow you to give
  several refund addresses, and random amounts of coins get refunded to
  each. @p{»»}

  @p{««}Then you need to trust that service, which is the really big
  security hole. What better way to catch money launderers than to setup a
  money laundering service for them? @p{»»}

  @p{««}You're probably better off doing what has been suggested several
  times@p{--} move coins between 'shared wallet' services like MyBitcoin
  or MtGox (and/or ClearCoin) or just between two machines of your own
  that are both running bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0406}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 20:58:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2477.msg34126@s{hash}msg34126
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't think that belongs in Bitcoin@p{--} I like solutions like
  i2p or ssh tunneling that put encryption down at the lower network layer
  (where it belongs, in my humble opinion). @p{»»}

  @s{quotedtext}

  @p{««} Are you worried about SourceForge and GitHub (the two 'official'
  trees) being forced, or deciding, to drop bitcoin? At this point lots of
  developers have their own copies of the source code, I'm sure if that
  happened another site (maybe a hidden monotone repository inside the
  anonymous i2p network) would spring up. @p{»»}

  @p{««}They can't stop the signal... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0407}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 21:12:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2367.msg34128@s{hash}msg34128
@section 3 {tx}

  @s{quotedtext}

  @p{««} Let's try using the github Pull Request system for discussing pull
  requests: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}That ties the discussion to the proposed code changes, is a natural
  way to create separate 'threads', and will be a convenient place to
  point to in release notes. @p{»»}

  @p{««}And lets talk about potential code changes (pre pull request) here
  in this forum. @p{»»}

  @p{««}I'd rather not introduce Yet Another Place (we've already got these
  forums, IRC chat, and github) to talk about bitcoin development. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0408}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 21:18:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2485.msg34130@s{hash}msg34130
@section 3 {tx}

  @p{««}I think of this as a subset of the "I want to move N bitcoins from
  my wallet to a USB stick that I'll put in my safe deposit box so it
  cannot be hacked", "bitcoins as a long-term store of value" feature:
  @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}issue/2@p{link)} @p{li)}

  @p{««}A solution should: @p{»»}

    @p{(li}@p{(li} Make accidental double-spending impossible (or at
    least, very hard) @p{li)} @p{(li} Remove the private keys from your
    wallet so if the wallet is stolen they coins are safe @p{li)} @p{(li}
    Be as close to 100% safe as possible, even if your computer gets hit
    by lightning at exactly the wrong time. @p{li)}

  @p{««}That last one is the tricky bit. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0409}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 21:28:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2522.msg34135@s{hash}msg34135
@section 3 {tx}

  @p{««}I'd love to see a pure-Javascript front-end GUI for bitcoind
  developed. @p{»»}

  @p{««}I'm tempted to write one myself, but I've got a lot of other things
  on my TODO list right now. Here's what I'm imagining: @p{»»}

  @p{(li}  Open source, pure JavaScript interface to bitcoin that
  communicates with a running bitcoin/bitcoind using the JSON-RPC api.
   @p{li)}

  @p{(li}  Open up the index.html page that is the GUI and you'd be asked
  for the host:port (default: localhost:8332), username and password.
   @p{li)}

  @p{(li}  From there, you'd have a nice Javascript/HTML GUI showing all
  your wallet transactions (using RPC listtransactions).  @p{li)}

  @p{(li}  And it'd show your default receiving address, have a Send
  Bitcoins button, etc.  @p{li)}

  @p{(li}  And it'd poll bitcoin/bitcoind every, oh, minute or so to look
  for new transactions.  @p{li)}

  @p{««}I'm imagining shipping a webGUI/index.html (plus associated
  CSS/javascript/etc) as part of the bitcoin(d) source package. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0410}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-29 23:40:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2522.msg34175@s{hash}msg34175
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, definitely not. But if somebody implements a nice Javascript
  GUI I'll volunteer to teach bitcoin to spit out JSONP in addition to
  plain JSON to get around the same origin policy... @p{»»}

  @p{««}RE: GWT: I'd prefer a non-Java-to-Javascript-compiled solution
  (shipping compiled, not-human-readable .js files makes me nervous; do we
  have to add all the GWT compilation mechanism to the build process? Or
  do we have to trust that you provided valid, not-messed-with,
  already-compiled .js files?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0411}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 04:11:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2526.msg34251@s{hash}msg34251
@section 3 {tx}

  @s{quotedtext}

  @p{««}If you have a trojan on your computer you've already lost. The
  trojan could easily log your keystrokes and send your password along
  with the encrypted wallet.dat to the bad guys. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0412}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 04:31:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2273.msg34258@s{hash}msg34258
@section 3 {tx}

  @p{««}There really is no "from" @p{--} there is just 'where the coins
  were sent last time they were sent somewhere.' @p{»»}

  @p{««}If that 'somewhere' was a shared wallet (like a mybitcoin account)
  where all the incoming transactions get mixed up, knowing what address
  they were sent to previously is worse than useless information. You
  might decide it is a good idea to try to refund bitcoins to that address
  and end up sending them to some random mybitcoin user, and NOT your
  customer. @p{»»}

  @p{««}Adding possibly-worse-than-useless features to the bitcoin GUI is a
  bad idea. Am I missing some other reason for wanting to see the last
  addresses to which the coins you received were sent?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0413}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 04:42:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2526.msg34264@s{hash}msg34264
@section 3 {tx}

  @p{««}Playing devil's advocate for a moment: @p{»»}

  @p{««}"Security theater" is popular. It makes people feel safer.
  Bitcoin-the-program will probably be more popular if it asks for a
  password before sending and there is a bullet-point on the feature list:
  "State of the art AES-256 encryption." @p{»»}

  @p{««}I believe TrueCrypt is open source; maybe it would be easy to use
  their password handling / encryption code in bitcoin. Anybody here
  looked at their code? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0414}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 17:12:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2537.msg34413@s{hash}msg34413
@section 3 {tx}

  @p{««}Yeah, cool! @p{»»}

  @p{««}Could you punch a couple of holes through the B? I like
  topologically interesting money. @p{»»}

  @p{««}And if you want to make it the absolutely coolest coin in the
  world, generate a new bitcoin address, send 1 bitcoin to it, and then
  engrave that address on the coin. @p{»»}

  @p{««}Then you have physical currency that the owner can independently
  check to make sure the bitcoin backing it hasn't been spent. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0415}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 23:47:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2026.msg34507@s{hash}msg34507
@section 3 {tx}

  @s{quotedtext}

  @p{««} The forum database is now being automatically compress, encrypted,
  and backed up to another of sirius' servers and to Amazon S3 every day
  (one per day, I don't delete the old backups, yet). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0416}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-30 23:55:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2273.msg34508@s{hash}msg34508
@section 3 {tx}

  @p{««}I agree it is natural to want to know who sends you the money. That
  would be a nice feature to add to Bitcoin. @p{»»}

  @p{««}Showing a 'from' address in bitcoin as it is now won't give you
  that feature, it will give you something that kind-of, sort-of,
  maybe-most-of-the-time works like that feature. @p{»»}

  @p{««}And it's not obvious how to implement a "where did these bitcoins
  come from?" feature. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0417}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-31 15:59:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2551.msg34612@s{hash}msg34612
@section 3 {tx}

  @p{««}Happy New Year! @p{»»}

  @p{««}It is going to be a good year. It has to be@p{--} because my
  favorite number is eleven. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0418}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2010-12-31 20:06:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1958.msg34649@s{hash}msg34649
@section 3 {tx}

  @s{quotedtext}

  @p{««}Thanks! It was the first interview I've ever done via IM/chat, and
  it worked well. I was surprised to see how little editing/reworking was
  done; I guess they were happy with what I wrote, too. @p{»»}

  @s{quotedtext}

  @p{««} Sure. I run two instances of bitcoind on a "Linode 512" running
  Debian (sign up @p{(link}using this URL@p{link)} and I'll get a $20
  credit). They're used for the TEST and regular Bitcoin Faucets. @p{»»}

  @p{««}I also use that system to compile bitcoin/bitcoind. I've been very
  happy with Linode. @p{»»}

  @p{««}The bitcoind for ClearCoin is running on an Amazon EC2 "micro" VPS
  instance, also running Debian, using an encrypted EBS filesystem. I'm
  extra paranoid about security and reliability for ClearCoin because I'm
  handling other people's money.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0419}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-02 17:02:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2566.msg34985@s{hash}msg34985
@section 3 {tx}

  @s{quotedtext}

  @p{««} It aught to be able to handle hundreds of accounts and thousands
  of addresses, although (as far as I know) nobody has done
  scalability/stress testing with that many (simulated) users. @p{»»}

  @p{««}The listtransactions method scans through all wallet transactions
  (and then sorts them by time), so if you've got thousands or tens of
  thousands of accounts with millions of transactions and you're using
  listtransactions to show customers their account histories, that might
  be a bottleneck. @p{»»}

  @p{««}However, I wouldn't be at all surprised if something ELSE becomes
  the bottleneck if you had that many accounts@p{--} for example, there is
  only one RPC thread handling requests, and some requests (like a send
  bitcoins request) can take seconds to process. I've been writing code
  long enough to know that I can't look at code (even code I've written)
  and figure out where the performance problems are lurking@p{--} you've
  got to actually measure or simulate real-world behavior. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0420}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-03 16:22:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2577.msg35150@s{hash}msg35150
@section 3 {tx}

  @p{««}Mirroring all of the information that bitcoin keeps about
  transactions inside your bitcoin-oriented web app is probably not the
  right way to go. @p{»»}

  @p{««}It violates the zero/one/infinity principle, and you're likely to
  have subtle bugs if (when?) the two copies get out of sync. @p{»»}

  @p{««}See: @s{(link)} for "best practices". If you're willing to share
  what kind of thing your web app is doing, I'd be happy to brainstorm
  other approches, too... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0421}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-03 17:08:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2367.msg35157@s{hash}msg35157
@section 3 {tx}

  @s{quotedtext}

  @p{««}Done. Please feel free to make it better. @p{»»}

  @s{quotedtext}

  @p{««} Good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0422}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-03 17:20:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2367.msg35159@s{hash}msg35159
@section 3 {tx}

  @s{quotedtext}

  @p{««} OK. Lets talk here. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0423}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-03 19:44:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2437.msg35188@s{hash}msg35188
@section 3 {tx}

  @p{««}Pulled into the git integration repository. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0424}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-03 19:52:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2404.msg35189@s{hash}msg35189
@section 3 {tx}

  @p{««}Pulled into git integration repository. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0425}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-05 12:28:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2624.msg35580@s{hash}msg35580
@section 3 {tx}

  @p{««}You should be honest about what you're doing: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0426}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-05 15:10:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2623.msg35604@s{hash}msg35604
@section 3 {tx}

  @p{««}Very nice! Let me ask some dumb questions: @p{»»}

  @s{quotedtext}

  @p{««} What does PPA stand for? @p{»»}

  @p{««}Does launchpad help solve the 'trusted build' problem@p{--} e.g.
  does the build process automatically fetch from source code that we can
  all look at and audit? @p{»»}

  @p{««}How hard would it be to setup something similar to produce regular
  builds of the github integration repository? @p{»»}

  @p{««}Right now, the bitcoin build process is "Satoshi does it." Using
  Launchpad to create the Linux builds seems like the right way to go.
  @p{»»}

  @p{««}Last dumb question: are there services similar to Launchpad for
  building Mac/Windows software? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0427}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-05 15:15:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2624.msg35606@s{hash}msg35606
@section 3 {tx}

  @p{««}trapezoid.... are you related to @p{(link}Dr. Gene Ray, Cube
  Phenomenologist and THE WISEST HUMAN@p{link)}? @p{»»}

  @p{««}In the programming world, I'm a fan of what is called "duck typing"
  @p{--} if it looks like a duck, walks likes a duck, and quacks like a
  duck, then it is a duck, even if you give it a fancy name like
  TrapezoidalFowl or MultiLevelBird. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0428}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-05 19:38:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2629.msg35659@s{hash}msg35659
@section 3 {tx}

  @p{««}CIA... sounds scary! @p{»»}

  @p{««}I'll make it post to @s{hash}bitcoin-dev @p{»»}

  @p{««}By the way: I cleaned up the SourceForge project a bit today,
  adding a pointer to the Technical Support forum here for support and
  shutting off some unused features. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0429}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-06 00:10:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=369.msg35711@s{hash}msg35711
@section 3 {tx}

  @s{quotedtext}

  @p{««} Done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0430}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-06 00:13:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2623.msg35712@s{hash}msg35712
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... but Launchpad won't @p{(bf}build@p{bf)} (run the compiler on
  one of their machines) Mac/Windows software, or did I miss that feature
  when I looked at the website? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0431}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-06 18:38:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2647.msg35879@s{hash}msg35879
@section 3 {tx}

  @p{««}I've been reworking my old 'monitorreceived' patch to catch up with
  the latest JSON api changes, and I'm looking for feedback. @p{»»}

  @p{««}New methods I've already implemented: @p{»»}

  @p{««} @s{code}: POSTs a
  JSON-RPC notification to @p{lt}url@s{gt} when new blocks are
  accepted.@p{li)}

    @p{(li}listmonitored : returns list of URLs that are monitoring new
    blocks@p{li)}

    @p{(li}getblock @p{lt}depth@s{gt} : Returns information about block at
    depth @p{lt}depth@s{gt}@p{li)}

  @p{««}getblock/monitorblocks give this information (this is one of the
  -testnet blocks): @p{»»}

  @s{code}

  @p{««} @s{code} The monitor JSON-RPC notification wraps that
   information with a call to "monitorblock" @p{--} see @s{(link)} for
   exactly what a notification looks like. @p{»»}

  @p{««}I'm thinking about adding notification for 0-confirmation wallet
  transactions, too; something like: @p{»»}

  @p{««}monitortx @p{lt}url@s{gt} (monitor=true) : POST to url when wallet
  transactions (sends and receives) are accepted. @p{»»}

  @p{««}Information posted would be the same as you get from calling
  gettransaction, and I'll change listmonitored to return lists of @s{code}. @p{»»}

  @p{««}Possible reasons @p{(bf}NOT@p{bf)} to add this to mainline bitcoin:
  @p{»»}

    @p{(li} 1. I'm using boost::xpressive (regular expression library) to
    parse the urls. Bitcoin is already dependent on lots of other pieces
    of Boost, and xpressive is compiled as a header-only dependency (no
    changes to the Makefiles)... but I wouldn't be surprised if using
    xpressive causes problems on SOME compiler somewhere. @p{li)}

    @p{(li} 2. POSTing to https: URLs won't work if you're running on
    Windows (any windows/mingw experts want to take another crack at
    getting full openssl working?). @p{li)}

    @p{(li} 3. Related to https/ssl: if you POST transactions to a non-ssl
    url, somebody eavesdropping on your packets will be able to figure out
    which bitcoin addresses belong to you. This is a potential privacy
    issue. @p{li)}

  @p{««}As always, feedback, encouragement, and reality-checks are welcome.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0432}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 15:01:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2662.msg36122@s{hash}msg36122
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. I vote for the new wiki as the right spot, with the
  Discussion pages there as the place to bring up issues with the
  documentation/etc. @p{»»}

  @p{««}I'll put a pointer to the new wiki at the beginning of my
  bitcointools NOTES.txt. @p{»»}

  @s{quotedtext}

  @p{««} Do we need a separate forum specifically for network-related
  stuff? Seems to me the Development forum here is the right place for
  those kinds of discussions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0433}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 15:29:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2657.msg36128@s{hash}msg36128
@section 3 {tx}

  @p{««}The smartcard-generates-a-private-key-itself seems like overkill.
  No matter what, you have to trust the smartcard manufacturer. Because
  even if the smartcard generates a private key, you have to trust that
  the smartcard manufacturer didn't: @p{»»}

    @p{(li}@p{(li} Add a backdoor that lets them read the private key
    @p{li)} @p{(li} Break the implementation so the private key created is
    predictable @p{li)}

  @p{««}If you have to trust the smartcard manufacturer anyway, it seems to
  me a much simpler solution is to just associated a bitcoin address with
  a tangible bitcoin. @p{»»}

  @p{««}Redeeming the tangible bitcoin then means turning it over to the
  issuer and having them send the bitcoins to one of your addresses. @p{»»}

  @p{««}It is easy to solve half of the "is this valid" problem@p{--} you
  can easily check to see if bitcoins have been sent to that address and
  are still unspent. @p{»»}

  @p{««}The other half of the problem is "is there another unredeemed copy
  out there?" @p{»»}

  @p{««}Perhaps the issuer could publish a public database of unredeemed
  tangible bitcoins that is: @p{»»}

    @p{(li}bitcoin address @p{--}@s{gt} hash of information that the
    tangible bitcoin purchaser provides @p{li)}

  @p{««}I could then check that database to see if bitcoin address 1abc was
  sold ONLY to SHA256("Gavin Andresen 1-Jan-2011"). That stops the issuer
  from selling the same bitcoins over and over again. @p{»»}

  @p{««}I still have to trust that the issuer won't decide to spend all the
  bitcoins (since they have the private keys) and disappear. But that's
  really no different from trusting your smartcard manufacturer. @p{»»}

  @p{««}(interesting thing to think about: the issuer could actually use
  just one private key and generate as many public keys as they like that
  can all be signed using that one private key...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0434}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 17:23:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2207.msg36152@s{hash}msg36152
@section 3 {tx}

  @p{««}Great! I'd like to see this good work make it back into mainline
  bitcoin; please talk with the other improve-the-build-process efforts
  and submit some patches. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0435}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 17:23:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=379.msg36153@s{hash}msg36153
@section 3 {tx}

  @p{««}Great! I'd like to see this good work make it back into mainline
  bitcoin; please talk with the other improve-the-build-process efforts
  and submit some patches. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0436}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 17:23:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=454.msg36154@s{hash}msg36154
@section 3 {tx}

  @p{««}Great! I'd like to see this good work make it back into mainline
  bitcoin; please talk with the other improve-the-build-process efforts
  and submit some patches. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0437}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 17:24:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2575.msg36155@s{hash}msg36155
@section 3 {tx}

  @p{««}Great! I'd like to see this good work make it back into mainline
  bitcoin; please talk with the other improve-the-build-process efforts
  and submit some patches. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0438}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 19:18:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2671.msg36189@s{hash}msg36189
@section 3 {tx}

  @p{««}@s{(link)} @p{brk} This adds a new field to the output of
  gettransaction @p{lt}txid@s{gt} : "details" @p{»»}

  @p{««}It is an array of objects containing
  account/address/category/amount (and maybe fee). For most transactions
  to or from your wallet, it will contain just one object, but for sends
  from one account to another it will contain multiple objects. @p{»»}

  @p{««}Example output: @p{»»}

  @s{code}

  @p{««} I'm not sure "details" is the right name for this information; if
  you have a better suggestion, speak up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0439}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-07 19:23:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2672.msg36190@s{hash}msg36190
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}Cross Origin Resource Sharing lets servers support cross-origin
  Javascript. It is supported by the latest browsers (although IE support
  is... different), and involves sending CORS headers in responses. @p{»»}

  @p{««}Adding this enables Javascript code running in a browser to connect
  with any bitcoin/bitcoind that allows RPC connections from the browser's
  IP address and has the right rpc username/password. @p{»»}

  @p{««}Code changes are minimal (4 lines of code to output CORS headers).
  Thanks to tcatm for implementing and testing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0440}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-09 17:44:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2699.msg36682@s{hash}msg36682
@section 3 {tx}

  @p{««}I agree with mh@p{--} if there are real compatibility issues or
  weaknesses, then those would be a good reason to switch curves. @p{»»}

  @p{««}If there aren't, sep256k1 seems plenty good enough for the
  forseeable future. I think most programmers (myself included) have a
  tendency to worry about small-probability "what if" problems that we
  know how to solve, when we'd be better off thinking about
  high-probability problems that we don't want to think about because we
  don't already know how to solve them. @p{»»}

  @p{««}Like multifactor wallet authentication so trojans don't steal
  users' wallets.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0441}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-09 17:57:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2062.msg36684@s{hash}msg36684
@section 3 {tx}

  @p{««}The CPU miner code has all sorts of now-mostly-worthless (because
  GPU mining is so much more energy-efficient than CPU mining)
  optimizations. Maybe hardened Linux doesn't like the assembly code or
  SSE instructions? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0442}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-10 00:32:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2698.msg36793@s{hash}msg36793
@section 3 {tx}

  @p{««}"Just turn on Berkeley db encryption and you're done" @p{--} ummm:
  @p{»»}

  @p{««}First, unless I'm reading the bdb docs wrong, you specify a
  password at database creation time. And then can't change it. @p{»»}

  @p{««}So, at the very least, somebody would have to write code that
  (safely) rewrote wallet.dat when you set or unset or changed the
  password. @p{»»}

  @p{««}Second, encrypting everything in wallet.dat means you'd have to
  enter your wallet password as soon as you started bitcoin (because user
  preference are stored in there right now), when ideally you should only
  enter the password as you're sending coins. @p{»»}

  @p{««}And third, there are all sorts of usability issues with passwords.
  Users forget their passwords. They mis-type them. I wouldn't be terribly
  surprised if doing the simple thing and just encrypting the whole wallet
  with one password resulted in more lost bitcoins due to forgotten
  passwords than wallets stolen by trojans. @p{»»}

  @p{««}I think creating a safe, useful wallet protection feature isn't
  easy, and there a lot of wrong ways to do it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0443}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-10 16:12:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2713.msg36951@s{hash}msg36951
@section 3 {tx}

  @p{««}I wrote a blog post about peak oil a couple of years ago: @p{brk}
   @s{(link)} @p{»»}

  @p{««}I still believe my conclusion: we'll be fine. We'll use less oil
  and more of something else. After all we survived Peak Whale Oil (you
  know, whale oil, that essential commodity that was so great for
  high-tech oil lanterns). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0444}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-11 12:53:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2672.msg37207@s{hash}msg37207
@section 3 {tx}

  @p{««}davout said (at the github pull request): @p{»»}

  @s{quotedtext}

  @p{««} If you've opened up access to the rpcport, then I don't think CORS
  support adds any significant vulnerability to password brute-forcing. I
  suppose it means a 10-year-old non-programmer can repeatedly enter a
  username and password into a website to try to brute-force your
  rpcpassword... but anybody capable of writing or running a script could
  just write a brute-forcer that doesn't run in a browser. @p{»»}

  @p{««}And, come to think of it, turning on CORS explicitly wouldn't stop
  the ten-year-old, either: they could just repeatedly browse to URL
  @s{(link)} and try different usernames/passwords. @p{»»}

  @p{««}Also, bitcoind already has anti-brute-forcing code. @p{»»}

  @p{««}The only security vulnerability I could imagine with CORS is that
  it might encourage people to add: @p{»»}

    @p{(li}rpcallowip=* @p{li)} ... to their bitcoin.conf, so they can
  connect to bitcoin from any IP address. And I worry that they might not
  bother to setup SSL, in which case their rpc username/password will be
  sent across the net in the clear. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0445}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-11 15:22:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2731.msg37232@s{hash}msg37232
@section 3 {tx}

  @p{««}Character set issues give me headaches. @p{»»}

  @p{««}So I just ran a test at the command-line, moving 500 testnet
  bitcoins to an account named "@s{BTC}" @p{»»}

  @p{««}The account created is named "\u00E0\u00B8\u00BF", which is not
  what I intended. E0 B8 BF is the utf-8 representation of the unicode
  Thai Baht character. @p{»»}

  @p{««}Thinking this through, trying hard not to get a headache... @p{»»}

  @p{««}My terminal window has: LC_CTYPE=en_US.UTF-8 @p{brk} So when I
  copy&amp;paste the Thai baht symbol, it is being encoded as UTF-8. @p{»»}

  @p{««}I pass a UTF-8 string to bitcoind, and it uses the JSON-Spirit
  library to convert it into a JSON string (which is defined to be
  Unicode... encoded using backslashes, I think: see @s{(link)} ). And
  there's the bug. Maybe. I think? @p{»»}

  @p{««}Command-line bitcoind should be looking at the locale and
  converting JSON strings to/from that locale. Anybody motivated enough
  about internationalized account names (and send comments) to teach it to
  do that? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0446}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-11 17:54:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2672.msg37268@s{hash}msg37268
@section 3 {tx}

  @s{quotedtext}

  @p{««} CORS support doesn't change this. @p{»»}

  @p{««}IF the browser has a bug that lets JavaScript code read the local
  filesystem, THEN JavaScript code can get your rpc username/password from
  your bitcoin.conf file. @p{»»}

  @p{««}And IF the JavaScript code can do that, then it can send rpc
  commands to bitcoind running on localhost (because, surprisingly, the
  same-origin policy does NOT apply to localhost: urls@p{--} we learned
  that lesson here six months or so ago). @p{»»}

  @p{««}That is all true right now, with the released bitcoin/bitcoind.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0447}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-11 21:25:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2731.msg37313@s{hash}msg37313
@section 3 {tx}

  @p{««}RE: point you in the right direction: @p{»»}

  @p{««}File rpc.cpp, the CommandLineRPC method: @p{»»}

  @p{««}I suspect what needs to be done is to properly JSON encode any
  strings passed via the command line. @p{»»}

  @p{««}And then properly decode/recode any strings returned from the JSON
  RCP call before printing out the result. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0448}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-12 01:22:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2745.msg37373@s{hash}msg37373
@section 3 {tx}

  @p{««}Should we start a betting pool to see how long it takes Google to
  decide bitcoin mining should be against its terms of service? @p{»»}

  @p{««}I think.... three months. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0449}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-13 15:00:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2621.msg37660@s{hash}msg37660
@section 3 {tx}

  @p{««}That is wxWidgets' internationalization machinery complaining
  about... something (the catalog is probably the list of english strings
  -@s{gt} other language strings). @p{»»}

  @p{««}As for fixing it: "Not It!" (I don't know nothing about wxWidgets
  internationalizations stuff)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0450}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-13 21:40:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2772.msg37771@s{hash}msg37771
@section 3 {tx}

  @p{««}The list of possible new features and bugs at @s{(link)} is getting
  longer every day; I'd like to see the bugs resolved before the bug list
  gets so long we all just start ignoring it. @p{»»}

  @p{««}So: who is willing and able to help out? Don't ask permission, just
  jump in, grab a bug that catches your interest, add comments to it as
  you start to figure out what the problem is (or isn't), and submit a
  PULL request when you have a fix. @p{»»}

  @p{««}Your reward will be recognition, admiration and respect. It is time
  to take bitcoin from, essentially, a single-programmer project to a
  robust open source project with lots of contributors. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0451}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-15 00:29:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2772.msg38162@s{hash}msg38162
@section 3 {tx}

  @s{quotedtext}

  @p{««} Improving help is definitely helping@p{--} thanks! @p{»»}

  @p{««}And it would be fantastic to get somebody who knows, or is willing
  to learn, git to step up and volunteer to submit translation file
  patches. @p{»»}

  @p{««}I'll soon be asking for building and testing help, too (after
  fixing another couple of bugs, I think it'll be time to pull
  non-controversial patches into the integration tree and start some
  serious testing to prepare for another release). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0452}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-15 22:35:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2306.msg38439@s{hash}msg38439
@section 3 {tx}

  @s{quotedtext}

  @p{««} There's one tricky accounts-related bug that I think needs to get
  fixed before the next release: @p{»»}

    @p{(li} @p{(link}@s{(link)}@s{hash}issue/25@p{link)} @p{li)}

  @p{««}The only other possibly critical bug is: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}issue/28@p{link)} @p{li)}

  @p{««}... although I haven't been able to reproduce it, even running
  bitcoind on top of the 'valgrind' memory checker. @p{»»}

  @p{««}I plan to pull patches into the integration git branch early next
  week, and I'll ask for help testing the result.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0453}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-16 15:23:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2828.msg38628@s{hash}msg38628
@section 3 {tx}

  @p{««}Adjusting the testnet difficulty every, oh, say 100 blocks (instead
  of 2016) seems like a good idea to me. @p{»»}

  @p{««}That's a trivial patch; I nominate ArtForz and Xelister to write it
  and submit a pull request. @p{»»}

  @p{««}Locking in the testnet block chain@p{--} not so much. I don't think
  it is worth the effort to either come up with a mechanism for
  distributing the lock-in points or manually put lock-in points in the
  source code. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0454}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-17 17:00:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2830.msg39021@s{hash}msg39021
@section 3 {tx}

  @p{««}As the owner of the Faucet, and having seen how far some people
  will go to get more than their fair share of bit-pennies from the
  Faucet, I've thought about this subject. @p{»»}

  @p{««}My conclusion is that instead of creating tools to try to become
  "the Bitcoin Police", there are probably better things you can do with
  your time. Because as soon as you create the tools, the bad guys will
  find ways to work around them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0455}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-17 18:42:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2853.msg39053@s{hash}msg39053
@section 3 {tx}

  @p{««}I'm thinking of replacing the Bitcoin Faucet's reCAPTCHA with an
  @p{(link}AdsCaptcha@p{link)} @p{--} instead of solving a CAPTCHA to help
  scan books, people visiting the site would be shown advertising which
  would help refill the Faucet with bitcoins. @p{»»}

  @p{««}My goal isn't to make money from freebitcoins.appspot.com, my goal
  is to make it sustainable without relying on donations. According to the
  AdsCaptcha folks, they expect advertisers pay anywhere from 1 to 20 US
  cents per CAPTCHA solution, depending on web traffic, how well the
  website fits their product, etc. The Faucet is currently giving out 0.05
  bitcoins per visitor, which is 2 cents at current prices. @p{»»}

  @p{««}I would also like to gradually relax some of the anti-cheating
  measures I have in place that occasionally make it frustrating for
  non-cheating new users who "look like" people who are constantly
  re-visiting the Faucet (using proxies and new bitcoin addresses) to try
  to get more than their fair share. @p{»»}

  @p{««}One danger is that I implement AdsCaptcha, donations to the faucet
  stop, I find the revenue from AdsCaptcha is less than 0.01 BTC per
  visitor so that whole thing is even less sustainable than the current
  "somebody steps up and donates more when the balance gets low enough"
  model. @p{»»}

  @p{««}What do you all think? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0456}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-18 00:19:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2853.msg39140@s{hash}msg39140
@section 3 {tx}

  @p{««}ribuck: The Faucet is currently giving out between 5 and 6 BTC per
  day (100-200 payouts per day). @p{»»}

  @p{««}BioMike: Are you creating an AdWords-like service, but
  bidding/paying in Bitcoin? One reason I like AdsCaptcha is because if
  won't clutter up the Faucet page with ads. @p{»»}

  @p{««}(mike): Thanks for the pointers RE: how much it costs to get
  google/yahoo/etc accounts; I have been tempted to give out more coins
  from the Faucet to people with Google accounts. @p{»»}

  @p{««} I'm going to give AdsCaptcha a try; if the ads are annoying or
  offensive or inappropriate or doesn't work with ad blockers I'll switch
  back to reCaptcha. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0457}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-18 19:38:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2672.msg39306@s{hash}msg39306
@section 3 {tx}

  @p{««}I don't think we have consensus that CORS in bitcoin is a good
  idea, so I'm not going to pull this now. @p{»»}

  @p{««}tcatm's little proxy server is a good workaround. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0458}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-19 14:11:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2868.msg39458@s{hash}msg39458
@section 3 {tx}

  @p{««}I paid for the download; nice little paper. And interesting choice
  of pseudonym. @p{»»}

  @p{««}Are you submitting it somewhere to get it peer reviewed? @p{»»}

  @p{««}And do you mind me asking what you mean by "I'm a computer
  scientist with some knowledge in cryptography" @p{--} are you a
  professor, grad student, postdoc,
  graduated-with-a-degree-in-computer-science-and-now-working-in-industry
  ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0459}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-19 14:33:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=989.msg39460@s{hash}msg39460
@section 3 {tx}

  @s{quotedtext}

  @p{««} Satoshi is busy. Doing what, I have no idea@p{--} maybe he's
  working on a GPL-version of bitcoin, but I doubt it. @p{»»}

  @p{««}In any case, I wouldn't expect any opinion on GPL versus MIT from
  him. @p{»»}

  @p{««}My opinion: I've got better things to do than worry about which
  open source license is most appropriate. No software license has magical
  powers that will prevent 'bad guys' from trying to do bad things. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0460}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-20 00:22:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2772.msg39588@s{hash}msg39588
@section 3 {tx}

  @s{quotedtext}

  @p{««} Having spent a lot of time working with the existing code, I don't
  think splitting the code into multiple files would make it much easier
  to work with. The hard part is figuring out how everything fits together
  (for example "if I have a CWalletTx, how do I get the CBlock that it is
  in (if any)?"). Just rearranging the code that is there now won't make
  that problem any better. @p{»»}

  @s{quotedtext}

  @p{««} I don't think anybody who has worked on the code, except for
  Satoshi, has a lot of bitcoins. I certainly don't. I hope to earn some
  with Clearcoin.... @p{»»}

  @s{quotedtext}

  @p{««} The listaccounts bug is nearly fixed. I cannot reproduce the
  dangerous-looking bug, even running bitcoind under the valgrind
  memory-checking tool (valgrind actually simulates machine instructions
  to catch memory access errors)@p{--} tcatm seems to be the only person
  having the issue. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0461}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-20 02:57:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=589.msg39621@s{hash}msg39621
@section 3 {tx}

  @p{««}Run one instance normally. It'll listen for incoming bitcoin
  network connections on port 8333, rpc connections on port 8332, and
  connect to other nodes. @p{»»}

  @p{««}Run the other instance with a different -datadir, and a
  bitcoin.conf like this: @p{brk} nolisten=1 @p{brk} rpcport=7332 (or
  whatever you like) @p{brk} noirc=1 @p{brk} connect=127.0.0.1:8333 @p{»»}

  @p{««}You'll need to be running the latest source code from github for
  the nolisten option. @p{»»}

  @p{««}The noirc and connect settings aren't strictly necessary; leave
  them out and the second instance will make 8 outgoing connections to
  other bitcoin nodes. You'll save a little network bandwidth if the
  nolisten instance only connects to the other node.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0462}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-20 21:03:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2893.msg39912@s{hash}msg39912
@section 3 {tx}

  @p{««}I think you should begin by defining the threat model. @p{»»}

  @p{««}Can the attacker see all unencrypted IP traffic to/from the
  sender's node, or is the traffic tunneled through an anonymizing network
  like i2p or tor? @p{»»}

  @p{««}Does the attacker know any of the sender's receiving bitcoin
  addresses? Is the attacker willing and/or able to send 'marked bitcoins'
  to the sender? Lots of them? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0463}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 00:16:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2901.msg39978@s{hash}msg39978
@section 3 {tx}

  @p{««}First: I am not a lawyer. @p{»»}

  @p{««}Second: No. @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0464}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 01:51:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2904.msg40014@s{hash}msg40014
@section 3 {tx}

  @p{««}I spoke with the author last week; I think she did a great job
  explaining bitcoin for a not-super-technical audience and does a great
  job being realistic about the hurdles bitcoin faces: @p{»»}

  @p{««} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0465}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 03:03:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2893.msg40031@s{hash}msg40031
@section 3 {tx}

  @p{««}If the threat model is as zipslack describes, then I think a "send
  to self" mixnet would work. @p{»»}

  @p{««}Patch bitcoin so it generates, a random transaction every, oh, I
  dunno, eight hours or so, sending, oh, I dunno, 1/10'th or so of your
  bitcoins back to yourself via a newly generated address. @p{»»}

  @p{««}And to erase your trail in case your wallet gets seized, remove the
  source transactions and their (spent) keys from your wallet. @p{»»}

  @p{««}After a week of doing that you'll have put 21 extra transactions on
  the network and, on average, four extra transactions on the coins in
  your wallet (four because every send typically generates a change
  transaction). Do it constantly and you'll have an ever-churning wallet
  that aught to foil any attempt to connect incoming @p{lt}-@s{gt}
  outgoing transactions. @p{»»}

  @p{««}That is all assuming that you don't start with zero bitcoins in
  your wallet, get exactly 111.11 bitcoins from somebody, spend a couple
  weeks mixing them, and then pay exactly 111.11 bitcoins to somebody
  else. That transaction network graph is easy to analyze, and it would be
  insanely unlikely that you "just happened" to receive exactly those same
  111.11-worth of coins that were given out. @p{»»}

  @p{««}Hmm, I wonder if the patch could detect a bad mix and warn you if
  you tried to do something stupid like that... @p{»»}

  @p{««}Somebody who knows a lot more about mixnets than I do can probably
  work out the math to know how much, and what type, of randomness to add
  to the eight hours and 1/10th to make statistical analysis as difficult
  as possible. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0466}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 15:26:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2893.msg40163@s{hash}msg40163
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, after posting I realized that self-mixing creates a
  mostly-self-connected sub-graph. You really need to start with multiple
  transactions in, ideally randomly occuring during the mixing process,
  and not spend all your bitcoins at once. @p{»»}

  @p{««}Somebody who knows a lot more about graph theory, statistics, and
  probability than I do should chime in and tell me how I'm wrong or come
  up with a good metric for the ideal amount of mixing (I bet too much is
  just as bad as too little). Analyzing the connectedness of the existing
  bitcoin transaction graph might be a good place to start. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0467}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 16:15:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2901.msg40173@s{hash}msg40173
@section 3 {tx}

  @s{quotedtext}

  @p{««} Publicly announce where? @p{»»}

  @p{««}Publicly announce it here and one of the moderators will delete it
  faster than you can type 'rm'. @p{brk} Announce it on your own website
  and I'd encourage the legal authorities and/or your ISP to shut you
  down. @p{»»}

  @p{««}Announce it in IRC chat or via a Freenet/TOR/i2p hidden service and
  I would personally encourage everybody to shun and /ignore you... and
  very few people will hear your announcement, anyway. @p{»»}

  @p{««}I suppose you could try to get a journalist or government
  interested in causing trouble for bitcoin to publicly announce it. If
  you did, I would ask as loudly as I could why the journalist or
  government is complaining about innocent bitcoin users instead of trying
  to track you down and prosecute you. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0468}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 16:57:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2908.msg40181@s{hash}msg40181
@section 3 {tx}

  @p{««}Because the first byte in a bitcoin address is a version number,
  and "version 0" is encoded as a "1" in the bitcoin address "base58
  encoding" (because 0 is too easy to confuse with capital-o). @p{»»}

  @p{««}Trivia: -testnet addresses are version 111 (eleven is my favorite
  number), and begin with m or n (I haven't actually worked out whether
  they might begin with another letter, too...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0469}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-21 22:21:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2908.msg40262@s{hash}msg40262
@section 3 {tx}

  @s{quotedtext}

  @p{««} I wrote a 'vanity bitcoin address' patch a while ago that lets you
  do exactly that: @s{(link)} @p{»»}

  @p{««}I bet finding an address starting 1HAL... wouldn't take more than a
  few hours. If I recall, it took a day or so to find one with the string
  'gavin' in it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0470}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-22 02:57:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2900.msg40307@s{hash}msg40307
@section 3 {tx}

  @p{««}Just to be sure: "removed all bitcoin data" means you removed and
  reinstalled bitcoin.exe ? @p{»»}

  @p{««}RE: wallet works fine on ubuntu: did you happen to run the wallet
  on another machine, then copy it back to your windows machine? @p{»»}

  @p{««}I don't know what to suggest@p{--} I'm not a Windows person...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0471}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-22 16:50:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2926.msg40424@s{hash}msg40424
@section 3 {tx}

  @p{««}It is time to build and test a new version of bitcoin. @p{»»}

  @p{««}In the past, Satoshi built the Windows and Linux releases, Laszlo
  built the Mac releases, and we trusted them not to put malware in them
  (or we compiled ourself from source). @p{»»}

  @p{««}Satoshi is busy, and even if he wasn't he shouldn't be spending his
  time doing a job that a lot of the rest of us are capable of doing. So
  we need a new process. @p{»»}

  @p{««}Ideally, that process should be open and verifiably trustworthy. So
  I'd like to propose that we do the following: @p{»»}

    @p{(li} 1. For each platform, somebody creates a pristine,
    reproducible build environment, preferably as a virtual machine image
    that anybody can download, inspect, clone, run, etc. @p{li)}

  @p{««}Anybody should be able to reproduce the build environment by
  running or following a script (e.g. "Install Ubuntu X.Y.Z. apt-get the
  following versions of the following packages... etc"). @p{»»}

    @p{(li} 2. A copy of that virtual machine is used to build/package the
    release. @p{li)}

    @p{(li} 3. Anybody can audit the process by re-creating the build
    environment and ensuring that they end up with "identical"
    executables. (where "identical" means compare the code in the
    executables, ignoring timestamps or other meta-info linkers put into
    executables @p{--} are there already tools to do that, or do we need
    to roll our own?). @p{li)}

  @p{««}Feedback? Suggestions for improvement, or are there better ways of
  creating 'trusted builds' ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0472}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-22 20:54:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2915.msg40493@s{hash}msg40493
@section 3 {tx}

  @s{quotedtext}

  @p{««} "Bitcoin, the New Zimbabwe Dollar" would be TERRIBLE marketing.
  How about a nice, respectable country that is just tired of using
  somebody else's currency? If the value of the dollar keeps falling,
  there may be a lot of those in the next 20 years. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0473}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-22 21:08:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2062.msg40497@s{hash}msg40497
@section 3 {tx}

  @p{««}BioMike: any progress tracking this down? @p{»»}

  @p{««}I just committed a fix to the git integration tree CallCPUID code
  to declare ebx/edx clobbered... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0474}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-23 14:05:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2939.msg40684@s{hash}msg40684
@section 3 {tx}

  @p{««}The number of confirmations tells you which block a transaction is
  in: @p{brk} 0 confirmations: not in a block yet. @p{brk} 1 confirmation:
  in block number "getblockcount" block. @p{brk} 2 : getblockcount-1
  @p{brk} ... etc. @p{»»}

  @p{««}Note that if there is a block chain reorganization which block the
  transaction is in can change (as can the number of confirmations). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0475}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-23 14:47:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2940.msg40700@s{hash}msg40700
@section 3 {tx}

  @s{quotedtext}

  @p{««} It will have only 8 (outgoing) connections. @p{»»}

  @p{««}With fewer connections, it will notice new blocks a tiny bit more
  slowly than the other machine, and blocks it finds will propagate to the
  rest of the network slightly more slowly than the other machine. So it
  will spend a teeny-tiny bit more time working on an out-of-date block
  chain, and will be a teeny-tiny bit more likely to lose "announce a new
  block" races. But I bet the effects are so small you'd never notice
  them. @p{»»}

  @s{quotedtext}

  @p{««} Yes and yes and no. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0476}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-23 15:18:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2923.msg40708@s{hash}msg40708
@section 3 {tx}

  @s{quotedtext}

  @p{««} FreeMoney is absolutely right. @p{»»}

  @p{««}The only way to get 80 people to accept the same 400 bitcoins would
  be to control all of their bitcoin connections and feed them different
  versions of the block chain. @p{»»}

  @p{««}And THAT will be impossible, because the people you're trying to
  rip off (merchants selling stuff) are exactly the people with
  long-running, well-connected bitcoin nodes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0477}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-23 17:18:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2923.msg40732@s{hash}msg40732
@section 3 {tx}

  @s{quotedtext}

  @p{««} You are confusing "control 50+% of generating power" with "control
  connections." @p{»»}

  @p{««}Lets say you control 51% of the generating power. @p{»»}

  @p{««}You can: @p{»»}

  @p{««}Spend bitcoins once. Then wait for them to be confirmed by the rest
  of the network as many times as the merchant requires, while secretly
  working on another version of the block chain where you did NOT spend
  them. Your secret block chain should be longer than the network's, since
  you control 51% of the generating power. @p{»»}

  @p{««}So you announce your secret block chain, and instead of sending
  those coins to a merchant you include a transaction where you send them
  to yourself. YEAH! you just ripped off the merchant! Wahoo! @p{»»}

  @p{««}You cannot rip off two merchants with the same bitcoins@p{--} one
  or the other of the transactions will be seen as valid. @p{»»}

  @p{««}And you cannot "unspend" the transaction to the merchant@p{--} if
  you don't spend it SOMEWHERE, the merchant's bitcoin node will
  re-announce it to the network and all the other nodes will consider
  those bitcoins "spent, just waiting to be included in the next generated
  block." @p{»»}

  @p{««} If you run the numbers again with the realistic double-spend
  scenario, you'll see crime doesn't pay. There is no way you can rent
  enough hashing power to commit a profitable double-spend attack. @p{»»}

  @p{««}If you can steal the hashing power (maybe you're a bot farmer),
  then if you run the numbers you'll find it is more profitable to just
  generate blocks and sell the bitcoins rather than try to somehow get
  stuff trying to double-spend. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0478}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-23 18:45:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2923.msg40744@s{hash}msg40744
@section 3 {tx}

  @p{««}From the Quora question: @p{»»}

  @s{quotedtext}

  @p{««} You can't spend 400 BTC 80 times in 1 hour. If you control a
  majority of the generation you could spend them twice an an hour
  (assuming merchants require 6 confirmations). @p{»»}

  @p{««}So you need to divide your expected profit per hour by 40, making
  your ROI very, very negative. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0479}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-24 14:16:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2952.msg40969@s{hash}msg40969
@section 3 {tx}

  @p{««}There are: @p{»»}

    @p{(li}1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
    possible bitcoin addresses. @p{li)}

  @p{««}As ribuck says, that is a very big number. There are approximately:
  @p{brk}
  133,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
  @p{»»}

  @p{««}.. @p{(link}atoms in the Earth@p{link)}, so even if you used just
  100 atoms to store each bitcoin address, you'd run out of atoms before
  you were done generating addresses. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0480}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-24 15:25:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2062.msg40981@s{hash}msg40981
@section 3 {tx}

  @p{««}What version of gcc are you using? After a little googling I found
  @p{(link}this thread@p{link)} about the same issue: @p{»»}

  @s{quotedtext}

  @p{««} Unless somebody volunteers to fix/maintain this, I'm inclined to
  simply remove all of the "try to make the CPU miner go faster"
  optimizations from bitcoin. CPU mining is, for most people, a waste of
  electricity. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0481}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-24 16:57:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg40999@s{hash}msg40999
@section 3 {tx}

  @p{««}Please checkout the git integration branch from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and help test. The new features that need testing are: @p{»»}

  @p{««}-nolisten : @s{(link)} @p{brk} -rescan : scan block chain for
  missing wallet transactions @p{brk} -printtoconsole : @s{(link)} @p{brk}
  RPC gettransaction details : @s{(link)} @p{brk} listtransactions new
  features : @s{(link)} @p{»»}

  @p{««}Bug fixes that also need testing: @p{»»}

  @p{««}-maxconnections= : @s{(link)} @p{brk} RPC listaccounts minconf :
  @s{(link)} @p{brk} RPC move, add time to output : @s{(link)} @p{brk}
  ...and several improvements to @p{--}help output. @p{»»}

  @p{««}@p{(bf}This needs more testing on Windows!@p{bf)} Please drop me a
  quick private message, email, or IRC message if you are able to do some
  testing. If you find bugs, please open an issue at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0482}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-24 21:35:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2956.msg41046@s{hash}msg41046
@section 3 {tx}

  @p{««}getbalance '*' 1 @p{»»}

  @p{««}... will do what you want in the next version of bitcoin. I need
  people to help download and build and test it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0483}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 02:55:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2962.msg41132@s{hash}msg41132
@section 3 {tx}

  @s{quotedtext}

  @p{««} It will create 100 keypool entries the first time you request a
  new address or if you turn on coin generation (the mining threads each
  ask the keypool for an address to create the coinbase transactions).
  @p{»»}

  @p{««}I don't know what the story is with "wkey".@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0484}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 14:19:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2956.msg41272@s{hash}msg41272
@section 3 {tx}

  @p{««}getinfo and getbalance (with no arguments)... are a little
  complicated. @p{»»}

  @p{««}They include all 1 confirmation receive transactions, but (this is
  the complicated part) they also include 0-confirmation receives if they
  are self-sends (either the "change" from coins you just sent or all the
  coins if you sent to one of your own addresses). @p{»»}

  @p{««}In any case, I think they will do exactly what you want@p{--} show
  you coins that have at least one confirmation or that you are certain
  you are able to spend (because they are your own 0-confirmation coins).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0485}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 14:31:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg41275@s{hash}msg41275
@section 3 {tx}

  @s{quotedtext}

  @p{««} You must have compiled against a newer version of Berkeley DB, and
  it uses a new log file format. Try removing the ~/.bitcoin/log.* files
  before running the older bitcoin version. @p{»»}

  @p{««}I changed build-unix.txt as you suggested. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0486}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 14:36:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg41278@s{hash}msg41278
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. Unless you're changing your wallet outside of bitcoin,
  rescanning isn't necessary. @p{»»}

  @p{««}It would be nice if the GUI had "backup wallet" and "merge backed
  up wallet with current wallet" options@p{--} the "merge wallet" would
  need do a rescan. Maybe next release somebody will implement those
  features... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0487}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 15:58:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2926.msg41301@s{hash}msg41301
@section 3 {tx}

  @p{««}ribuck: what do you suggest instead? @p{»»}

  @p{««}I've read Ken Thompson's paper; that is what motivated me to
  propose a reproducible virtual machine image as the best we can do
  @p{(bf}IN PRACTICE@p{bf)}. @p{»»}

  @p{««}Yes, it is theoretically possible somebody might sneak
  bitcoin-stealing code into the gcc compiler. Code that detects that
  bitcoin is being compiled and injects instructions to send coins to the
  sneaky gcc hacker. @p{»»}

  @p{««}In reality, we trust that the gcc maintainers are trustworthy and
  careful and that they care about their reputations. If you don't trust
  them, what is the alternative? @p{»»}

  @p{««}Nefario: can "we" make building bitcoin easier? I've been asking
  people to submit patches to the bitcoin linux build process, but so far
  none have been forthcoming... @p{»»}

  @p{««}devrandom: Nice! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0488}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 18:00:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2926.msg41317@s{hash}msg41317
@section 3 {tx}

  @p{««}ribuck: I did misunderstand, sorry. @p{»»}

  @p{««}And maybe I should have been clearer: the idea behind a
  @p{(bf}reproducible@p{bf)} virtual image is exactly to capture tools,
  version numbers, etc etc. Auditors that create their own virtual images
  with the same CPU, OS, tools, etc. will be relied upon to confirm that
  yes, the bitcoin executables on the website were indeed built using
  standard compilers/linkers/etc from a particular source revision. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0489}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 18:06:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2965.msg41319@s{hash}msg41319
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure there is@p{--} block 0 contains coins 0-49, block 1 coins
  50-99, etc. @p{»»}

  @p{««}If you get sent 500 bitcoins, they can all be traced back to
  generation transactions, so you "own" a bunch of little pieces of land
  in bitcoin-world. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0490}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-25 18:10:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2969.msg41322@s{hash}msg41322
@section 3 {tx}

  @p{««}Answering the original question: @p{»»}

  @p{««}Arresting counterfeiters is a good government economic
  intervention. @p{»»}

  @p{««}A counterfeit-proof currency like bitcoin is better, of course.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0491}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-26 00:13:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2965.msg41422@s{hash}msg41422
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's easy@p{--} if @s{hash}5 is the lowest ordinal piece of dust, then
  it goes to the first txout. Etc. @p{»»}

  @p{««}It's all arbitrary but deterministic, and all recorded in the block
  chain, so you could define rules to trace every .0000000001-of-a-bitcoin
  forward through transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0492}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-28 00:36:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=241.msg42004@s{hash}msg42004
@section 3 {tx}

  @s{quotedtext}

  @p{««} That would make an odd transaction pattern@p{--} e.g. if you
  started with 11 bitcoins in your wallet, you'd generate a chain of
  transactions that was: @p{»»}

  @p{««}A paid B 11 bitcoins @p{brk} B paid C 11 bitcoins @p{brk} C paid D
  11 bitcoins @p{brk} ... etc, every 6 hours. That makes it obvious what
  you're doing (a series of exactly-11-bitcoin transactions would be
  extremely unlikely). @p{»»}

  @p{««}Ideally, you want the graph of transactions involving your coins to
  be indistinguishable from a random sub-graph of the entire bitcoin
  transaction graph. Creating lots of wallets won't help you do that; you
  need to mix your coins with other people's, so the mixing looks the same
  as just ordinary "X paid Y" transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0493}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-28 01:50:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3018.msg42017@s{hash}msg42017
@section 3 {tx}

  @p{««}I made a google spreadsheet with the number of transactions
   occurring in the bitcoin block chain per month, and the total value of
   those transactions: @p{brk}
   @p{(link}@s{(link)};hl=en&amp;gid=0@p{link)} @p{brk} (click on the
   BitcoinTransactions spreadsheet; the first is just another version of
   @s{hash}produced over time) @p{»»}

  @p{««}Looks like bitcoin is growing nicely; I'm not sure why the big
  spikes in July and October... @p{»»}

  @p{««}I made the calculations using my bitcointools python code: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0494}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 00:16:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3025.msg42267@s{hash}msg42267
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, not "everybody" @p{--} if it is too expensive for you, then
  you stop doing it. Only the people who can generate most efficiently
  will stick around, and they'll stop "going hard" when the cost of adding
  more generating hardware is more than the value of the bitcoins they
  get. @p{»»}

  @p{««}Hopefully bitcoins will become more valuable over time (that will
  happen if people find them useful/valuable). @p{»»}

  @s{quotedtext}

  @p{««} Mostly no, total value of the transaction doesn't matter. A
  large-value transaction that is made up of lots of little transactions
  is more expensive to verify, but so is a small-value transaction made up
  of lots of tiny transactions. And for both, if they're big enough
  they'll have to include a transaction fee to get accepted. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0495}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 01:42:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3028.msg42288@s{hash}msg42288
@section 3 {tx}

  @p{««}Can you back up and describe what problems your patches solve?
  @p{»»}

  @p{««}Here are the problems I care about: @p{»»}

  @p{(li}  If a user receives 1.000001 bitcoins, there is currently no way
  to transfer the entire amount somewhere else using either the GUI or the
  RPC.  @p{li)}

  @p{(li}  If a user receives 1.000001 bitcoins, the GUI will tell them they
  have 1.00.  @p{li)}

  @p{««}I don't care about systems without a FPU@p{--} are there any such
  systems that bitcoin actually runs on? @p{»»}

  @p{««}I don't care about BTC vs TBC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0496}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 02:28:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3034.msg42292@s{hash}msg42292
@section 3 {tx}

  @p{««}luke-jr's patches got me thinking about whether or not passing
  double-precision values over the JSON-RPC api would ever cause problems.
  I've convinced myself it isn't an issue: @p{»»}

  @p{««}JSON numbers are 64-bit double-precision floating point values,
  which have 53 bits of precision. @p{»»}

  @p{««}21 million bitcoins is actually 2,100,000,000,000,000 (2.1
  quadrillion) of the smallest possible unit. That's a bit over 2^(51)
  @p{--} you need just over 51 bits to represent them. @p{»»}

  @p{««}So, unless your JSON library is buggy, you should never run into
  rounding errors converting to/from JSON, even if you're sending
  0.00000001 bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0497}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 02:29:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg42293@s{hash}msg42293
@section 3 {tx}

  @p{««}I haven't heard from anybody... I'll ask again: PLEASE HELP TEST
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0498}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 02:57:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2134.msg42296@s{hash}msg42296
@section 3 {tx}

  @s{quotedtext}

  @p{««} It sends it from the ClearCoin wallet. It doesn't do anything
  special to try to 'mix' coins, though, so if you send ClearCoin exactly
  11 bitcoins and then release exactly 11 it is pretty likely the
  transaction history would be easy to figure out. @p{»»}

  @p{««}Which reminds me... I released a new version of ClearCoin this week
  that lets you release an arbitrary amount. So if you wanted to pay
  somebody 11 bitcoins but make it hard to figure out where the payment
  came from by looking at the transaction histories you could: @p{»»}

  @p{««}Fund the escrow account with, oh, I don't know, 20 bitcoins.
  @p{brk} Release 11. @p{brk} Let the escrow expire, and you'll be sent
  the leftover 9. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0499}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 15:27:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3034.msg42423@s{hash}msg42423
@section 3 {tx}

  @p{««}ribuck: @p{»»}

  @p{««}Accuracy/precision is a red-herring unless you're treating numbers
  as strings, since JSON-RPC numbers ARE ALWAYS double-precision floating
  point numbers (according to the JavaScript/ECMAScript spec). Bitcoin
  could send a number that looks like 2100000000000001, but the code that
  interprets that JSON-RPC number will convert it into an inexact
  double-precision floating-point equivalent. And then the code that
  displays that number will have to decide how to round and format that
  inexact floating point number and display it to the user. @p{»»}

  @p{««}When we need more than 51 bits of precision (wouldn't THAT be a
  fantastic problem to have!), then we'd HAVE to send numbers as strings,
  and have the JavaScript (or whatever) on the other end feed them into a
  bignum-type library to handle them.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0500}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-29 21:30:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3034.msg42503@s{hash}msg42503
@section 3 {tx}

  @s{quotedtext}

  @p{««}From the jansson docs: @p{»»}

  @p{««}"integer numbers whose absolute values are too large to be
  represented in the int type will result in an overflow error" @p{»»}

  @p{««}As I said in the thread about possibly changing the ECDSA curve
  bitcoin uses, programmers like to solve "problems" that they know they
  can solve and that they think will make things a little bit better. But,
  in my humble opinion, unless you're solving an important problem
  changing things because you think you know how is often a bad idea.
  @p{»»}

  @p{««}This is a perfect example: change the RPC to spit out 64-bit
  integers (or move to a new RPC that spits out integers) and anybody
  using jansson on a 32-bit-int platform will get an overflow error. @p{»»}

  @p{««}I kind of like tcatm's suggestion to define new RPC methods that
  specify a base unit using strings... but then I thought more about it:
  @p{»»}

  @p{««}We could use scientific notation, so 1 BTC would be 1e08 base
  units; then if we ever needed more precision the JSON interface wouldn't
  change, you could just specify 1e-03 as a value.... @p{brk} ... but
  that's exactly what we have now. 1 BTC is 1e00, 1 base unit is 1e-08,
  and if we ever needed more precision the JSON interface is ready. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0501}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-30 18:03:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2931.msg42621@s{hash}msg42621
@section 3 {tx}

  @p{««}This seems like a good idea; maybe not for the next (0.3.20)
  release, but 0.3.21. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0502}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-30 18:25:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3051.msg42626@s{hash}msg42626
@section 3 {tx}

  @p{««}Difficulty on the -testnet is annoyingly high. I propose resetting
  the -testnet with a new genesis block, and changing the -testnet rules
  for difficulty adjustment as follows: @p{»»}

    @p{(li} 1. Adjust difficulty on the testnet every 126 blocks (1/16'th
  the regular net adjustment). @p{brk} 2. Keep the "difficulty can adjust
  up at most *4", but remove the limit on how quickly difficulty can
  adjust down. Minimal difficulty would remain the same. @p{li)}

  @p{««}Unless I hear howls of protest or better ideas, I'll generate a
  genesis block and submit a pull request with the changes. I won't switch
  the -testnet faucet to the new chain until we've got 0.3.20 release
  candidate builds out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0503}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-31 01:07:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3051.msg42724@s{hash}msg42724
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, if necessary we'd change the difficulty adjustment rules and
  make the code: @p{»»}

  @p{««}if (current block is @s{gt} some_number) @p{»»}

    @p{(li}... new rules for adjusting difficulty @p{li)} else @p{»»}

    @p{(li}... old rules for adjusting difficulty @p{li)}

  @p{««}I could have done that and kept the testnet block chain, but it is
  cleaner to just reset it with new rules. @p{»»}

  @p{««}And "pulling the same trick" means throwing an overwhelmingly
  massive amount of hashing power at the main network (like 16 times the
  current overall hashing power) for a significant amount of time, which
  is getting increasingly hard to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0504}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-31 14:24:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2926.msg42825@s{hash}msg42825
@section 3 {tx}

  @s{quotedtext}

  @p{««} Very nice! @p{»»}

  @p{««}Is there a standard spot to put the build descriptor file in the
  source tree, or a standard name for it? I'd like to commit the build
  descriptor file. @p{»»}

  @p{««}bitcoinex: I'll tag the tree when I think we have a release
  candidate. There are still a few loose ends I hope to tie up today:
  @p{»»}

    @p{(li} 1. New -testnet genesis block. @p{brk} 2. New block chain
  lock-in point. I'm thinking block 105,000 is a good candidate for the
  lock-in point. @p{brk} 3. Compile/run/sanity test on Windows. I am
  planning on spinning up an Amazon EC2 Windows instance to create a
  build/testing environment (although probably a VMWare image would be
  better@p{--} can anybody help with this? I normally don't do windows).
  @p{li)}

  @p{««}Am I missing anything else stopping a 0.3.20 release candidate?
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0505}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-31 14:32:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3051.msg42827@s{hash}msg42827
@section 3 {tx}

  @p{««}Patch/pull request is: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0506}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-01-31 15:38:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3065.msg42844@s{hash}msg42844
@section 3 {tx}

  @p{««}I split this into it's own thread. @p{»»}

  @p{««}Here's a counter-proposal: @p{»»}

  @p{««}All RPC methods dealing with amounts take and report full-precision
  bitcoins. @p{brk} E.g. if you have 1 BTC getbalance reports 1.00000000
  (as it does now) @p{brk} The send and move methods will be changed to
  NOT round to two decimal places. @p{»»}

  @p{««}luke-jr's patch that makes bitcoin avoid creating sub-cent change
  (when possible) will be applied. @p{»»}

  @p{««}The GUI will be modified to display full precision amounts, and
  will allow full-precision sends. @p{»»}

    @p{(li}(if you have 1 BTC, GUI should show balance: 1.00 @p{li)}

    @p{(li} if you have 1.0001 BTC, GUI should show balance: 1.0001
    @p{li)}

    @p{(li} ...etc) @p{li)}

  @p{««}A new setting: maxtxfee will be added, default will be 0.01 BTC.
  RPC methods will fail with a new error message if a send/sendfrom would
  generate a transaction fee larger than maxtxfee. @p{»»}

  @p{««}A new RPC method to change maxtxfee setting (maybe a generic RPC
  method to change any run-time option that can be changed on the fly?)
  @p{»»}

  @p{««}The code should be checked and all references to CENT which really
  mean "minimum transaction fee" should be changed to reference a new
  "minimum transaction fee" constant (==CENT for now). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0507}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-01 13:38:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2022.msg43140@s{hash}msg43140
@section 3 {tx}

  @p{««}So... who's excited about doing either a little wxWidgets
  programming or a lot of "port the bitcoin GUI to Qt" programming? @p{»»}

  @p{««}This isn't going to happen unless somebody actually does it...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0508}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-01 17:51:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3070.msg43208@s{hash}msg43208
@section 3 {tx}

  @p{««}You can setup your own f2f bitcoin network using the -connect
  option, connecting only to friends. @p{»»}

  @p{««}One of those friends must be connected to the rest of the bitcoin
  world, of course. @p{»»}

  @p{««}Experimenting with sending transactions and blocks over XMPP or
  some other network is a great idea@p{--} go for it! It shouldn't be hard
  to create a "bitcoin bridge" that relays traffic on the main bitcoin
  network to/from another network. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0509}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-01 18:00:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg43212@s{hash}msg43212
@section 3 {tx}

  @p{««}0.3.20 will support listtransactions '*' for all transactions.
  @p{»»}

  @p{««}Transactions since @p{lt}txid@s{gt} .... sounds dangerous. Are you
  trying to mirror the transaction database that bitcoin keeps? If you
  are, are you sure you'll deal properly with (rare) block chain
  re-organizations where transactions that you thought had one
  confirmation turn out to be invalid in a new fork of the chain? @p{»»}

  @p{««}I can imagine subtle bugs@p{--} you ask for transactions since
  @p{lt}txid@s{gt} but that txid turns out to be an orphan transaction
  (double-spend on the losing side of a block chain re-org) so bitcoin
  returns... what? @p{»»}

  @p{««}All non-orphan transactions with transaction time equal to or
  greater than a given timestamp might work@p{--} but what is your use
  case? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0510}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-01 20:50:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg43288@s{hash}msg43288
@section 3 {tx}

  @s{quotedtext}

  @p{««} Two thoughts: @p{»»}

  @p{««}listaccounts (minconfirmations) (also new in 0.3.20, if I'm
  remembering correctly) will give you all accounts and their balances. If
  an account's balance doesn't change, you know it hasn't received coins.
  @p{»»}

  @p{««}And why do you need to periodically update the user's
  account/assets? Could you just query bitcoind for their current balance
  when they fetch their 'account status' page (or wherever you show the
  user how many bitcoins they have)? Are you doing something with the
  received bitcoins without an explicit action on the part of the user,
  and does that something care about the total balance or individual
  transactions? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0511}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 04:21:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3107.msg43457@s{hash}msg43457
@section 3 {tx}

  @p{««}Giving them all the same starting wallet is a bad idea; they will
  start out with the same keys, but will eventually each generate their
  own, so their balances will drift out of sync. @p{»»}

  @p{««}In theory everything should work out, but in practice using the
  same wallet on multiple machines hasn't been tested much (I fixed a
  couple of bugs in the last couple of weeks related to a wallet shared
  between machines). @p{»»}

  @p{««}So before cloning, delete the wallet.dat (assuming it has no
  bitcoins in it) and let the clones automatically generate a new wallet
  the first time they start. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0512}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 14:56:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3051.msg43587@s{hash}msg43587
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, it won't sort itself out "after a few weeks". Let me see if I
  can do a back-of-the-envelope: @p{»»}

  @p{««}Difficulty on testnet currently at 373. We want it no higher than,
  oh, 5, so with the typical 3-or-4 machines CPU-hashing on testnet
  generate a block in a reasonable amount of time. @p{»»}

  @p{««}So we generate 2016 blocks over 8 weeks. That cuts difficulty by
  four: ~90 @p{brk} Then do it again: ~22 @p{brk} and again... ~5 SIX
  MONTHS later @p{»»}

  @p{««}That's optimistically assuming we can find people to cooperate to
  contribute hashing power to generate 2016 blocks at difficulty 300 in 8
  weeks or less. @p{»»}

  @p{««}If you'd like to continue using the old testnet chain, be my guest.
  @p{»»}

  @p{««}I'm sympathetic to the "testnet and main net should have the same
  rules", but the truth is the testnet has, and always will have, many
  fewer people hashing on it. @p{»»}

  @p{««}Changing the main net downard-difficulty-adjustment code might make
  sense, but that's the topic for another thread. Allowing main net
  difficulty to adjust all the way from 22,000 to 1 isn't the right answer
  (it makes sybil attacks where an attacker feeds you a bogus version of
  the block chain much easier).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0513}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 16:10:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg43625@s{hash}msg43625
@section 3 {tx}

  @p{««}How do you think the code should deal with the issue of "a fixed
  txid might no longer be valid" ? Or transactions that you THOUGHT had N
  confirmations and were in a block with timestamp T are re-organized to
  have M confirmations and are in a block with timestamp T2 ? @p{»»}

  @p{««}tcatm and I chatted in IRC about this problem@p{--} he has the
  problem of how to keep the Javascript GUI (which shows you ever
  transaction) up-to-date. @p{»»}

  @p{««}Seems like you really want an efficient way of asking "Do I know
  about exactly the same set of transactions as bitcoind" (either for the
  entire wallet or for an account). That's assuming transaction data can't
  change (somebody double-check that assumption for me@p{--} if the
  transaction data changes, then the txid changes... I think). @p{»»}

  @p{««}That led to some brainstorming of computing a hash of all
  transaction ids (maybe just XOR them all together). Or maybe something
  more complicated like a merkle tree... but that seems like overkill.
  @p{»»}

  @p{««}Is there a good, simple solution to synchronizing "I have this set
  of stuff, give me everything I don't have" ?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0514}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 16:55:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3121.msg43647@s{hash}msg43647
@section 3 {tx}

  @p{««}Good idea. @p{»»}

  @p{««}I think the first spot for plugins in bitcoin should be "send
  address resolver" services@p{--} If I tell bitcoin "send 100 bitcoins to
  @p{(link}obama@s{at}whitehouse.gov@p{link)}" it could ask the plug-in
  resolvers (in some user-defined order) "do you have a bitcoin address
  for @p{(link}obama@s{at}whitehouse.gov@p{link)}" ? @p{»»}

  @p{««}If I tell bitcoin "send 100 bitcoins to eff.org" maybe a different
  resolver is used (DNSSec query to eff.org to get a bitcoin donation
  address, perhaps). Or "send 11 bitcoins to +01-1-805-253-2751" ... @p{»»}

  @p{««}There are lots of potential problems, of course, ranging from what
  if the resolver software service/author starts redirecting bitcoins to
  them to what if the user misspells the destination. That's why I think
  starting with a way of pluggin-in different solutions to try is the
  right way to start.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0515}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 17:07:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg43651@s{hash}msg43651
@section 3 {tx}

  @s{quotedtext}

  @p{««} Transactions are confirmed when new blocks are accepted; that's
  the idea behind my 95%-finished 'monitorreceived' code. It will POST to
  a URL when new wallet transactions and blocks are accepted. The block
  information includes all transaction ids (and a link to the previous
  block). @p{»»}

  @p{««}As you note, you still have the issue of what to do if your code
  misses a POST. That shouldn't be a big issue, though, because you'll
  resynchronize the next time a block is found. Worst case, you'll ship to
  the customer 1 block (10 minutes) later than is optimal if your
  connection to bitcoind is lost. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0516}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-02 17:35:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg43678@s{hash}msg43678
@section 3 {tx}

  @p{««}Nice, I like your proposal. @p{»»}

  @p{««}Do you know C++?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0517}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-03 18:03:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44064@s{hash}msg44064
@section 3 {tx}

  @p{««}If an optional time param is needed, maybe get rid of the "since
  @p{lt}txid@s{gt}" notion and just make it "give me all receive
  transactions for (account) with (minconfirmations) that have a time
  greater than (time)". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0518}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-03 19:01:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44083@s{hash}msg44083
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh? I don't see how passing @p{lt}txid@s{gt} makes that problem
  any better. @p{»»}

  @p{««}Let's say you've got transactions A B C D (in that order). With
  times T1, T1, T2 and T2 (A&amp;B happened 2 blocks back, you got C&amp;D
  in the last block). @p{»»}

  @p{««}Now imagine a block-chain re-org, so B and C are now invalid. @p{»»}

  @p{««}Ask for all transactions after D and you get nothing@p{--} same as
  if you asked for all transactions with time greater than T2. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0519}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-03 21:13:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44134@s{hash}msg44134
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, there is a block chain re-org invalidating B and C. D is still
  valid in my scenario. @p{»»}

  @p{««}So the client remains oblivious to B and C being invalid, whether
  it asks for transactions older than T2 or transactions after D. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0520}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-04 16:34:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44430@s{hash}msg44430
@section 3 {tx}

  @s{quotedtext}

  @p{««} The fool-proof way of dealing with your use case (customer orders
  something, you want to ship after you're sure payment has cleared):
  @p{»»}

  @p{(li}  Give each customer an account. When they order, use
  getaccountaddress to get a bitcoin address to which they can send
  payment.  @p{li)}

  @p{(li}  Every N minutes ask bitcoin either the balance (with minimum 6
  confirmations) for accounts with pending orders or all accounts  @p{li)}

  @p{(li}  If the account balance is enough to pay for the order, ship it
  and move the coins from the customer's account to a PAID account.  @p{li)}

    @p{(li} If not... either wait or tell the customer they paid the wrong
    amount or maybe refund any extra they sent (you'll have to ask them
    for a refund address). @p{li)}

  @p{««}The inelegant polling will eventually be fixed by bitcoin POSTing
  when new blocks or transactions arrive, but I think you'll still need to
  ask bitcoin what the account's current balance is@p{--} trust me, you
  really don't want to recreate all the bitcoin logic dealing with
  double-spent transactions or block chain reorganizations. @p{»»}

  @p{««}If you grow to handling thousands of orders per day (which would be
  a very good problem to have) you'll want to buy or build a version of
  bitcoin optimized for high-volume transaction websites. Or maybe you'll
  run 20 bitcoinds, each handling 1/20'th of the customers @p{--} I dunno,
  I don't spend a lot of time worrying about problems I'll have when my
  project is outrageously successful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0521}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-04 18:33:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44493@s{hash}msg44493
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure, every block has a unique hash. @p{»»}

  @p{««}But I don't think that helps at all; you might see that
  transactions A B C D are in block @s{hash}100,000 with hash H1, but after a
  block chain re-org block @s{hash}100,000 might contain transactions A D (with
  block hash H2). @p{»»}

  @p{««}The probability of that happening rapidly approaches zero as the
  block gets confirmed; after 6 confirmations you can safely assume it
  just won't happen. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0522}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-04 18:41:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3168.msg44500@s{hash}msg44500
@section 3 {tx}

  @s{quotedtext}

  @p{««} So if the merchant sees an attempted double-spend within 5 seconds
  they accept the bitcoins but don't give the
  merchandise/service/whatever. @p{»»}

  @p{««}That sounds like a good idea to me. Maybe instead of 5 seconds it
  aught to be "before the transaction is fully confirmed." @p{»»}

  @p{««}The only drawback I see is buggy clients that might have bugs that
  cause 'honest' double-spending mistakes. @p{»»}

  @p{««}Oh, and merchants would have to explain to customers whey they kept
  their double-spent coins (although the merchants could easily produce
  both transaction IDs to show the world that it WAS a double-spend, so
  they shouldn't have to worry about their reputation being sullied).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0523}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-04 19:02:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3170.msg44509@s{hash}msg44509
@section 3 {tx}

  @p{««}Good Idea. I think the PDF signing is overkill, but Good Idea.
  @p{»»}

  @p{««}Here's a bitcoin business I want somebody to create and run: "Coin
  on a Stick" @p{»»}

  @p{««}You sell USB sticks containing Mac and Windows versions of the
  latest bitcoin (including the entire block chain) plus a wallet file
  containing N bitcoins. @p{»»}

  @p{««}Sell them via Ebay or PayPal, and ship them ONLY to a
  PayPal-verified address. @p{»»}

  @p{««}The buyer has to trust you not to double-spend the coins in the
  wallet, and has to wait for delivery of the physical USB stick. But they
  don't have to download or install anything (they should be able to just
  run bitcoin from the stick and transfer the coins to themselves or a
  mybitcoin or mtgox account). @p{»»}

  @p{««}But, since you are sending a physical product to a verified
  address, you'll be treated as any other merchant selling real goods by
  PayPal or the credit card companies. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0524}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-04 19:53:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3170.msg44537@s{hash}msg44537
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, the delivery address and the fact that you're selling a
  physical product (the USB stick). @p{»»}

  @p{««}Kind of like how you used to be able to buy cheap OEM copies of
  software but they had to ship a token piece of hardware in the box so
  they could say they were hardware vendors... (actually, can you still do
  that any more?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0525}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-05 15:35:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3184.msg44783@s{hash}msg44783
@section 3 {tx}

  @p{««}Spend 80cents to lower the price of something 50cents (and give you
  the privilege to look at the price)? @p{»»}

  @p{««}Sounds like a terrible idea to me. @p{»»}

  @p{««}So it'll probably be a huge success (I'm constantly amazed at the
  stupid things people do with their money). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0526}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-05 16:31:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3118.msg44789@s{hash}msg44789
@section 3 {tx}

  @p{««}We've talked about these kinds of scaling issues in the past, and
  we've got a ways to go until they become an issue. @p{»»}

  @p{««}I still strongly believe that we shouldn't worry about them until
  they actually start to become a problem. @p{»»}

  @p{««}Long before we get to 300 million transactions per day there will
  be big companies spending lots of engineering dollars on their own
  highly optimized versions of bitcoin. @p{»»}

  @p{««}I bet there will be alternative, secure-and-trusted,
  very-high-speed network connections between major bitcoin transaction
  processors. Maybe it will just be bitcoin transactions flying across the
  existing Visa/MasterCard/etc networks (I have no idea what their
  transaction clearing/processing networks look like or how they work).
  @p{»»}

  @p{««}Instead of worrying about "what will we do when we are wildly
  successful" we should be worrying about "what should we do RIGHT NOW so
  we become wildly successful." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0527}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-05 17:13:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44802@s{hash}msg44802
@section 3 {tx}

  @p{««}It doesn't 'feel right' to me. @p{»»}

  @p{««}Seems like the ideal API would be: @p{»»}

  @p{««}"Hey bitcoin, I want to keep track of all transactions for account
  FOO (or all accounts) that have (minconf) confirmations. Please POST
  them to (url)." @p{»»}

  @p{««} or @p{»»}

  @p{««}"Hey bitcoin, I want to keep track of all transactions for account
  FOO (or all accounts) that have (minconf) confirmations. I'll be polling
  you to see if there are any new ones every once in a while, I'll pass
  you (unique_token) so you know it is me." @p{»»}

  @p{««}... at least for the simple case. You'd get back two lists of
  transactions: new transactions with (minconf) that you haven't been told
  about before (maybe empty in the polling case), and a list of
  transactions you were told about before that now have less than
  (minconf) confirmations because of a block chain re-org (always empty if
  (minconf) is big enough). @p{»»}

  @p{««}For the "I really want to shoot myself in the foot and deal with
  block-chain reorgs myself" you can call getblock and/or monitorblock to
  get all the gory details about which transactions are in which
  blocks.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0528}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-05 22:38:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3092.msg44861@s{hash}msg44861
@section 3 {tx}

  @s{quotedtext}

  @p{««} They're not in 0.3.20; maybe 0.3.21. @p{»»}

    @p{(li}@s{(link)} @p{li)} ... is the not-yet-ready-for-prime-time
  branch they're on. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0529}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-05 23:03:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3198.msg44868@s{hash}msg44868
@section 3 {tx}

  @p{««}In @p{(link}this thread@p{link)} I said: @p{»»}

  @s{quotedtext}

  @p{««} Bitcoin is still vulnerable to DOS attacks. I'm not sure anybody
  knows how to prevent DOS attacks on a p2p network that allows
  untrusted/unverified peers to join (but I'd very much like a networking
  expert to tell me I'm wrong, and would like it even more if they
  volunteered to fix it....). @p{»»}

  @p{««}Asking hackers to prove that they can DOS the bitcoin network
  wouldn't prove anything, it would just slow down transactions for
  however long they decided to keep up the attack. @p{»»}

  @p{««}Giving bounties for uncovering vulnerabilities besides a
  network-denial-of-service attack is a good idea (demonstrated on the
  -testnet, preferably). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0530}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-07 17:03:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3221.msg45366@s{hash}msg45366
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think it would be great for newbies who hear about bitcoin and
  decide they want to try it. @p{»»}

  @p{««}USB stick is better than a CD because you could include a recent
  copy of Bitcoin (with most of the block chain), already configured, for
  Windows and Mac. @p{»»}

  @p{««}So the user plugs in the USB drive, double-clicks the bitcoin app,
  and they're up and running. @p{»»}

  @p{««}The seller would need to establish a reputation for
  no-viruses/trojans, no already-spent coins in the wallet on the stick,
  etc etc etc.... @p{brk} ... all the stuff that newbies are probably to
  clueless to worry about anyway. @p{»»}

  @p{««}The value is both the "starter" bitcoins in the wallet AND the
  convenience of not having to download/install/configure bitcoin. If
  PayPal asked, I'd say that I'm selling bitcoin software on USB sticks,
  and that the bitcoins in the wallet are just there because you can't use
  the software without having a few bitcoins to start.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0531}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-07 20:40:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3034.msg45422@s{hash}msg45422
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh? Nobody is suggesting that any math be done with
  floating-point coins. @p{»»}

  @p{««}But even if we were, your first example gives the correct result to
   the 8-places-of-precision that Bitcoin deals with: @p{brk} (round
   0.032200000000000006 to 8 places and you get 0.03220000) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0532}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-08 16:21:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3230.msg45705@s{hash}msg45705
@section 3 {tx}

  @p{««}Wiki for the trade page is a fantastic idea. @p{»»}

  @p{««}And I like the idea of a re-organized, simplified home page. Who
  should the home page target? I think there are few potential audiences;
  successful web sites design their home pages to one or more specific
  types of visitors. For bitcoin, I think visitors are likely to be: @p{»»}

    @p{(li} 1. Geeks who are interested in "how is bitcoin supposed to
    work." @p{li)}

    @p{(li} 2. Geeks who are interested in "how can I use bitcoin for a
    project I'm thinking of working on." @p{li)}

    @p{(li} 3. Non-geeks who are interested in "what the heck is bitcoin
    and why should I care." @p{li)}

  @p{««}There are also several audiences I don't think bitcoin.org should
  target (for example, people hoping that bitcoin is a way to get rich
  quick). Am I missing anybody? @p{»»}

  @p{««}I've been busy putting together a 5-minute talk for audience number
  3; I think I can re-purpose some of what I wrote for the website. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0533}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-08 18:17:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3249.msg45748@s{hash}msg45748
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yup. @p{»»}

  @p{««}Patches welcome, although before accepting any more patches "we"
  need to build the 0.3.20 release. Assuming my cold doesn't get a lot
  worse, I'll be trying to make that happen tomorrow... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0534}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-08 18:23:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3263.msg45749@s{hash}msg45749
@section 3 {tx}

  @s{quotedtext}

  @p{««} Are you missing your wallet.dat file or is it damaged? @p{»»}

  @p{««}If it is missing, then grondilu's advice is the best anybody can
  do. @p{brk} If it is damaged, then it might be possible to extract the
  private keys from it. @p{»»}

  @p{««}This type of thing is why off-site backups are a really good
  idea... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0535}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-09 04:35:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3250.msg45885@s{hash}msg45885
@section 3 {tx}

  @p{««}-rescan will be in 0.3.20. @p{»»}

  @p{««}It takes about a minute right now on my machine (but that will get
  longer and longer as there are more and more transactions in the block
  chain). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0536}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-09 16:11:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=751.msg46056@s{hash}msg46056
@section 3 {tx}

  @s{quotedtext}

  @p{««} The public bug tracking/feature request system is at: @p{brk}
   @s{(link)} @p{»»}

  @p{««}Vote up issues/bugs that are important to you there. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0537}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-09 16:13:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2415.msg46060@s{hash}msg46060
@section 3 {tx}

  @p{««}The -rescan argument in 0.3.20 does this. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0538}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-10 14:44:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3311.msg46571@s{hash}msg46571
@section 3 {tx}

  @p{««}I wonder how much a bitcoin transaction actually costs, in terms of
  bandwidth and disk space on everybody's machines. @p{»»}

  @p{««}If nobody beats me to it, I'll try to do a back-of-the-envelope
  calculation later today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0539}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-10 17:13:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3311.msg46666@s{hash}msg46666
@section 3 {tx}

  @p{««}WAY too many issues being mixed up here... I'm sorry I ever framed
  this as "moving the decimal point" @p{»»}

  @p{««}I think the next release of Bitcoin should: @p{»»}

  @p{(li}  Show full-precision bitcoins in the GUI. If you have 1.5 BTC, it
  will display as it does now ("1.50").  @p{li)}

    @p{(li}If you have 1.50001 BTC, it will display the extra precision.
    @p{li)}

  @p{(li}  Allow you to send full-precision from the GUI and from JSON. If
  you have 1.500001 BTC, you will see  @p{li)}

    @p{(li}you have that many and can send that many. @p{li)}

  @p{(li}  Incorporate luke-jr's patch to avoid losing "dust change", when
  possible. (e.g. if you have received transactions of 1.5000001 and 20
  BTC, and then send 1.5, Bitcoin shouldn't choose just the 1.5000001
  input transaction).  @p{li)}

  @p{««}Those issues are being driven by pooled mining@p{--} a lot of
  people are getting sub-cent bitcoins from their pooled mining shares.
  @p{»»}

  @p{««} Then there's the issue of "what is a micro-transaction for which
  you should be forced to pay a fee." Currently, it is any transaction
  with an output less than 0.01 BTC. @p{»»}

  @p{««}And the issue of "what is the minimum fee" (also currently 0.01
  BTC). @p{»»}

  @p{««}Ideally, transaction fees should reflect real-world costs...
  although just making them hidden costs that are spread between everybody
  running bitcoin might work perfectly well. Still, I'd like to get a
  rough idea of the real-world cost of a transaction. @p{»»}

  @p{««} It is too early to be worried about "paying 0.001 bitcoins for a
  pair of socks".@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0540}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-10 17:26:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3311.msg46678@s{hash}msg46678
@section 3 {tx}

  @s{quotedtext}

  @p{««} Okey doke. And the default value should be.... ?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0541}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-10 22:24:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2647.msg46845@s{hash}msg46845
@section 3 {tx}

  @s{quotedtext}

  @p{««} Connects via another port? @p{»»}

  @p{««}Or would you teach bitcoin's minimal http implementation to keep
  the connection open? (and service multiple connections at once) @p{»»}

  @p{««}I've got a use case (google App Engine) where a persistent
  connection to bitcoin isn't possible (App Engine apps can fetch URLs,
  and can act as 'web hooks', but can't just open a socket and listen).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0542}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-10 22:55:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3332.msg46857@s{hash}msg46857
@section 3 {tx}

  @p{««}I figure each bitcoin transaction is currently costing about $US
  0.0003 (three-hundredths of a cent) @p{»»}

  @p{««}Here's the back-of-the-envelope calculation I used to get to that
  number: @p{»»}

  @p{««}Transaction size: ~300 bytes. @p{brk} Disk space cost: 0.05 $US per
  gigabyte (about $100 for a 2TB hard drive these days) @p{brk} Bandwidth
  cost: 0.02 $US per gigabyte @p{brk} CPU cost: 0 (bad assumption@p{--}
  anybody want to try to come up with a better estimate?) @p{»»}

  @p{««}Size of bitcoin network: ~10,000 nodes @p{»»}

  @p{««}Each transaction is currently sent across the network twice (once
   on its own, and once when it becomes part of a block). It is stored on
   disk once. So disk+bandwidth cost for one machine is: @p{brk}
   (0.05+0.02+0.02)*(300/1000000000) @p{brk} ... times 10,000 nodes gives
   $0.00027 per transaction. @p{»»}

  @p{««} Please check my work@p{--} I usually screw up and add or drop an
  extra zero when doing these types of calculations. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0543}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-11 15:10:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3332.msg47099@s{hash}msg47099
@section 3 {tx}

  @s{quotedtext}

  @p{««} I agree. However, at this point "we" have to decide what the
  default rules are, and what is decided now will influence what people
  think is "fair" two years from now (when, hopefully, bitcoin is in the
  process of becoming wildly successful). @p{»»}

  @p{««}Also, I've read a couple of popular behavioral economics books
  (e.g. Predictably Irrational), and I think there might be some
  irrationality that could make bitcoin more successful. For example,
  "free" is a magical number. If we can make most bitcoin transactions
  "free" to the typical user, then that's a huge selling point. @p{»»}

  @p{««}There ARE hidden costs; the reason I want to do the
  back-of-the-envelope is to figure out how big those hidden costs are now
  and how big they're likely to get in the future. It isn't rational, but
  most people would rather have "free transactions", even if they end up
  paying 10 cents more in electricity costs every month whether or not
  they actually make any transactions. @p{»»}

  @p{««}(I may move this to the Economics topic depending on where the
  discussion goes)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0544}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-11 15:39:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3332.msg47112@s{hash}msg47112
@section 3 {tx}

  @s{quotedtext}

  @p{««} Thanks Hal! @p{»»}

  @p{««}If I had a cluster of bitcoin transaction processing nodes (or a
  big mining farm), I'd connect them with memcache and store transaction
  hashes/verified flag pairs, so signatures were verified once. Or maybe
  just have one machine filter transaction/block traffic and only pass
  along valid transactions/blocks, and not have the rest of the machines
  even bother checking signatures. @p{»»}

  @p{««}It will be tougher for individual nodes. If they're not mining,
  they could just check signatures ONLY on somebody-sent-to-them
  transactions. @p{»»}

  @p{««}If they are mining... well, it seems to me single-node miners will
  become increasingly rare as bitcoin scales up. Hardware farms or miners
  using a mining pool seem like the way of the future. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0545}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-11 15:42:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3332.msg47115@s{hash}msg47115
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, that's the point: 0 is a magic number in our heads. @p{»»}

  @p{««}"1/50'th the cost of Paypal" will get, say, 5% of the people to
  switch. @p{»»}

  @p{««}"Free" will get 50% to switch. @p{»»}

  @p{««}(numbers pulled out of my ass, of course, but you get the
  idea)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0546}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-11 23:59:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3337.msg47468@s{hash}msg47468
@section 3 {tx}

  @p{««}The Faucet has several abuse prevention features in place. I'm not
  going to say what they are because then the 'bad guys' would have a road
  map for what to do to try to get around them. @p{»»}

  @p{««}They're not 100% foolproof, but they're pretty good. @p{»»}

  @p{««}The steady stream of transactions from the Faucet the last few days
  IS because of the increased interest due to the security now podcast and
  slashdot mention.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0547}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-12 01:11:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3341.msg47488@s{hash}msg47488
@section 3 {tx}

  @p{««}If you really want to sway people, you need to find areas of
  agreement and blissfully ignore things about which you strongly
  disagree. @p{»»}

  @p{««}There is a lot to agree with in that FAQ, in my humble opinion.
  @p{»»}

  @p{««}Oh, and you have to learn to ignore people who just won't listen to
  reason, or who are starting with different assumptions about how the
  world works than you. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0548}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-13 04:22:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3341.msg48080@s{hash}msg48080
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you're confusing libertarian with minarchist or
  anarcho-capitalist. @p{»»}

  @p{««}Libertarians generally agree that police and a legal system to
  resolve disputes are a proper role for government. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0549}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-13 04:31:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3393.msg48083@s{hash}msg48083
@section 3 {tx}

  @s{quotedtext}

  @p{««} Really? @p{»»}

  @p{««}You don't think if bitcoin gets really successful and there are
  hundreds of millions of dollars poured into engineering efforts for it
  (and if it is wildly successful, big companies WILL invest huge amounts
  of money on it), that any scaling problems won't get solved? @p{»»}

  @p{««}I bet I could find people predicting a few years ago that Facebook
  would never be able to scale to billions of users (it was written in PHP
  for pete's sake!). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0550}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-13 04:40:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3415.msg48085@s{hash}msg48085
@section 3 {tx}

  @p{««}It is possible to generate transactions that "fan out" to an
  arbitrary number of recipients. @p{»»}

  @p{««}They're non-standard transactions right now, so they won't be
  relayed or included in blocks. But you should probably assume that they
  will be possible in the future (and a miner could, of course, include
  them in their own blocks now). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0551}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-13 16:27:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3418.msg48270@s{hash}msg48270
@section 3 {tx}

  @p{««}I'm halfway through creating releases@p{--} I had a 0.3.20
  candidate Windows release that didn't pass sanity testing (rendering
  issues that it looks like are fixed with a wxWidgets upgrade). @p{»»}

  @p{««}If all goes well, 0.3.20 for linux and pc will be up and available
  tomorrow, 0.3.20 for the mac "real soon now". @p{»»}

  @p{««}If not... it will take longer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0552}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 16:14:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3459.msg48715@s{hash}msg48715
@section 3 {tx}

  @p{««}Easiest way would be to put it in the bitcoin.conf file. @p{»»}

  @p{««}Create $HOME/Library/Application Support/Bitcoin/bitcoin.conf and
  put: @p{»»}

  @p{««}connect=IP ADDRESS @p{»»}

  @p{««}... in it. Any of the command-line options (except -datadir and
  -conf) can be put in the bitcoin.conf file. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0553}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 16:34:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3457.msg48722@s{hash}msg48722
@section 3 {tx}

  @p{««}Here's what happens when you press the Get Some button on the
  Faucet and it sends you coins: @p{»»}

  @p{(li}  A Google App Engine task is scheduled to actually do the send.
   @p{li)}

  @p{(li}  The send tasks are (currently) scheduled to run at most once per
  minute, so huge spikes in demand for coins from the faucet are smoothed
  out.  @p{li)}

  @p{««}The nice thing about App Engine tasks is that they're persistent
  little buggers@p{--} they'll keep going until they succeed. If the send
  fails for some reason (I need to restart bitcoind for some reason, or
  the connection between the Google and my bitcoind server is down), App
  Engine will reschedule the task to try again after an hour. @p{»»}

  @p{««}So, you were probably just very unlucky and the send failed twice
  in a row, OR you on the tail end of a couple hundred people all asking
  for coins at about the same time (the faucet will service a maximum of
  120 requests in two hours). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0554}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 17:14:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg48736@s{hash}msg48736
@section 3 {tx}

  @p{««}Linux and Windows binaries are at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Summary of changes and new features (see pull requests for
  details): @p{»»}

  @p{««}-nolisten : @s{(link)} @p{brk} -rescan : scan block chain for
  missing wallet transactions @p{brk} -printtoconsole : @s{(link)} @p{brk}
  RPC gettransaction details : @s{(link)} @p{brk} listtransactions new
  features : @s{(link)} @p{»»}

  @p{««}Bug fixes: @p{»»}

  @p{««}New seed nodes : @s{(link)} @p{brk} New testnet genesis block :
  @s{(link)} @p{brk} Optimize database writes : @s{(link)} @p{brk}
  -maxconnections= : @s{(link)} @p{brk} RPC listaccounts minconf :
  @s{(link)} @p{brk} RPC move, add time to output : @s{(link)} @p{brk}
  several improvements to @p{--}help output. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0555}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 18:24:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg48770@s{hash}msg48770
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think the real danger is that a large mining operator would
  create a side business selling space in their blocks for these types of
  intentional double-spends. When they generate a block they could send a
  text message to a bunch of people saying "try to spend NOW". @p{»»}

  @p{««}I wonder if there's some way to discourage that kind of anti-social
  behavior; could the network detect that was being done and "shun" that
  miner's blocks? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0556}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 18:29:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3463.msg48771@s{hash}msg48771
@section 3 {tx}

  @p{««}Your second client hasn't downloaded all the blocks yet (according
  to the screen snapshot). @p{»»}

  @p{««}When it has, it will be able to verify that the send transaction is
  valid, and will update your balance there. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0557}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 20:43:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3473.msg48839@s{hash}msg48839
@section 3 {tx}

  @p{««}Please download and test the Windows and Linux release candidate
  builds of Bitcoin version 0.3.20.01: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Summary of changes and new features (see pull requests for
  details): @p{»»}

  @p{««}-nolisten : @s{(link)} @p{brk} -rescan : scan block chain for
  missing wallet transactions @p{brk} -printtoconsole : @s{(link)} @p{brk}
  RPC gettransaction details : @s{(link)} @p{brk} listtransactions new
  features : @s{(link)} @p{»»}

  @p{««}Bug fixes: @p{»»}

  @p{««}New seed nodes : @s{(link)} @p{brk} New testnet genesis block :
  @s{(link)} @p{brk} Optimize database writes : @s{(link)} @p{brk}
  -maxconnections= : @s{(link)} @p{brk} RPC listaccounts minconf :
  @s{(link)} @p{brk} RPC move, add time to output : @s{(link)} @p{brk}
  several improvements to @p{--}help output. @p{»»}

  @p{««} SHA1 sums (UPDATED for 0.3.20.01): @p{»»}

  @p{««}7dfbc05b36112f59886a29f044cfd21c6c253169
  bitcoin-0.3.20-linux.tar.gz @p{brk}
  2a4affd92dd11e0b759f90a8fa4bead58bdbf7b4 bitcoin-0.3.20-win32-setup.exe
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0558}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 21:12:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg48852@s{hash}msg48852
@section 3 {tx}

  @s{quotedtext}

  @p{««} Right... so then the question is "will the MYBITCOIN-like
  intermediary be able to verify transactions quickly without opening
  themselves up to systematic fraud." @p{»»}

  @p{««}Without requiring users to pre-deposit funds with them, because
  users ain't gonna do that. @p{»»}

  @p{««}Here's another possible simple rule for miners that might work
  (but, as Hal said, requires Deep Thought): @p{»»}

  @p{««}"When I see a new block with transactions that I didn't see
  broadcast previously, mark those transactions as suspicious. If I see
  double-spends of those transactions, stop building on that block@p{--}
  assume it is cheating. Switch to the previous block (or alternate block
  if there's a block race going on)." @p{»»}

  @p{««}Miners won't try to rip off a grocery store for $50 worth of
  groceries if doing so makes their $50+ bitcoin reward for finding a
  block disappear. @p{»»}

  @p{««}This rule would also give miners a strong incentive to detect and
  refuse to include EITHER side of a double-spend in their blocks (if they
  get both spends while they're working on the block). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0559}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 21:49:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg48869@s{hash}msg48869
@section 3 {tx}

  @s{quotedtext}

  @p{««} Submit issues at the issue tracker on github if you run into
  issues: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0560}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 22:39:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=175.msg48885@s{hash}msg48885
@section 3 {tx}

  @s{quotedtext}

  @p{««} Price swings won't settle down until: @p{brk} 1. The bitcoin
   economy is bigger (a "market cap" of hundreds of millions of dollars
   instead of just a few million dollars). @p{brk} and @p{brk} 2. Bitcoin
   is mature enough for people to really trust it. @p{»»}

  @p{««}Unless there is somebody out there with very deep pockets and a
  willingness to spend a lot of money smoothing out the fluctuations
  there's not a whole lot we can do about it besides make bitcoin better,
  easier to use, more secure, etc. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0561}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-14 22:55:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg48891@s{hash}msg48891
@section 3 {tx}

  @s{quotedtext}

  @p{««} Excellent point. Although there should be a meta-incentive to make
  the bitcoin system successful, so there are lots of transactions (and
  lots of transaction fees for the miners). Certainly big payment clearing
  houses that want instant payments to work have the right incentives...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0562}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 00:31:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3476.msg48948@s{hash}msg48948
@section 3 {tx}

  @p{««}I agree with jgarzik: the do-nothing @p{lt}@p{lt} 0 is basically a
  comment saying "this is a bit-field." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0563}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 00:42:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3324.msg48951@s{hash}msg48951
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yeah! Those damn socialists! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0564}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 01:36:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3473.msg48973@s{hash}msg48973
@section 3 {tx}

  @p{««}Mac binary uploaded to SourceForge (thanks to Laszlo, who builds
  the Mac versions). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0565}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 01:46:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3341.msg48976@s{hash}msg48976
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'd just like a rational system where policy changes are proposed
  along with specific, testable predictions for those policy changes.
  @p{»»}

  @p{««}Then the policy change is adopted. Evaluated after a little while.
  @p{»»}

  @p{««}And accepted or rejected based on whether or not the policy change
  had the intended effect. @p{»»}

  @p{««}Then maybe we could take turns adopting our favorite policies, and
  see if that nice liberal "inequality reducing" policy actually, you
  know, reduces inequality (and we could argue about whether it is OK to
  do if it reduces inequality by making rich people a lot less rich and
  poor people a little more poor). @p{»»}

  @p{««}Or if that nice libertarian "cost saving" policy actually, you
  know, saves money (and we could argue about whether the cost savings is
  worth it if it increases our chances of getting a scalp infection from
  an unlicensed barber). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0566}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 15:39:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg49292@s{hash}msg49292
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think it is a reasonable assumption that major miners will be
  well-connected with each other. There is certainly a strong incentive
  for miners to be well-connected in general (better connected == more
  likely to win 'block races'). @p{»»}

  @p{««}So I don't see how you could freeze the block chain@p{--} if you
  generate lots of double-spends, the miners will quickly see both of
  spends and will drop those transactions like hot potatoes. The "finney
  attack" only works if the first double-spend is generated by a miner
  that finds a block and includes it in the block without transmitting it.
  @p{»»}

  @p{««}Also, my proposal was to only reject blocks containing 'suspicious'
  transactions that you hadn't seen transmitted that have a double-spend
  attempt before the next block. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0567}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 19:07:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=717.msg49368@s{hash}msg49368
@section 3 {tx}

  @p{««}The help text is misleading; never pass the "foo=" part. @p{»»}

  @p{««}Somebody could teach bitcoin to accept either getreceivedbyaccount
  foo 10 or getreceivedbyaccount address=foo minconf=10 @p{brk} ... but
  maybe we should just change how the help text shows default arguments or
  improve the documentation. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0568}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 19:10:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3508.msg49371@s{hash}msg49371
@section 3 {tx}

  @p{««}2.1 quadrillion basic units should be plenty. The US M2 money
  supply is (according to Wikipedia) less than 1 quadrillion pennies.
  @p{»»}

  @p{««}If bitcoin is ever twice as popular as dollars, that would be a
  very good problem to have.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0569}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 19:50:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3514.msg49394@s{hash}msg49394
@section 3 {tx}

  @p{««}There is a bug in the 0.3.20 candidate release that causes
  rendering issues on Windows. @p{»»}

  @p{««}I have no idea how to fix it; I don't even have a real Windows
  machine on which to test it (I built 0.3.20 on an Amazon EC2 windows
  virtual machine). @p{»»}

  @p{««}Anybody willing to step up and fix it? @p{»»}

  @p{««}If nobody steps up and commits to continuing to develop the
  wxWidgets GUI, we may have to stop supporting/developing it and start
  releasing only bitcoind. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0570}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 21:47:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg49447@s{hash}msg49447
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm lost. Who are X and Y? You're going to spam the network with
  payments to X == yourself and Y == the corner grocery store in the hopes
  of... what? @p{»»}

  @p{««}Remember the original attack: @s{quotedtext}

  @p{««} Again, it seems to me some rules that make attempted double-spends
  more costly to those who attempt to pull off double-spends might be a
  good idea. @p{»»}

  @p{««}theymos' objection (that there's no real incentive for miners to
  try to detect/punish double spends) is worth thinking about. Is there
  enough "interest in the common good" for miners to spend some CPU cycles
  so that the bitcoin system as a whole is more robust, or would
  self-interest lead to a tragedy of the commons where miners do the
  absolute minimum to just get their blocks accepted? @p{»»}

  @p{««} bfever: my gut reaction is that the "fast payment problem" won't
  be solved by more complicated transactions. And my gut reaction to more
  complicated transactions is that that the more complicated something is
  the more likely it is to have security holes.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0571}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 21:56:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg49451@s{hash}msg49451
@section 3 {tx}

  @p{««}One more thought: the "finney attack" can only be profitable if the
  reward from cheating is greater than (reward of mining times the
  probability your block will be rejected because you delay announcing it
  while you "run down to the store"). @p{»»}

  @p{««}Reward for block is currently $50, that will (hopefully!) continue
  to rise for the next decade or two. @p{»»}

  @p{««}Say it takes you 5 minutes to complete a transaction at the corner
  store (half the average block gen time)... today you'd have to make a
  $25-or-greater purchase just to break even. @p{»»}

  @p{««}Seems likely this attack will be completely impractical for
  transactions under $200 when the block reward is worth more than $400.
  0-confirmations (just wait N seconds to look for a quick double-spend)
  for any transaction under $200 seems "good enough" to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0572}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-15 22:50:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3517.msg49475@s{hash}msg49475
@section 3 {tx}

  @p{««}The 5-minute Ignite! talk I did about Bitcoin is up: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}It was mostly what I wanted to say; I think I ended better than I
  started. My slides and script @p{brk} with exactly what I planned to say
  are here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Feel free to remix it. If I ever do another Ignite! talk (they're 5
  minute talks with slides that auto-advance ever 15 seconds) I'll plan to
  say less, try to interact with the audience more, and may hire somebody
  (with bitcoins, of course) to replace my text-heavy slides with more
  pretty pictures. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0573}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-16 14:13:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3517.msg49771@s{hash}msg49771
@section 3 {tx}

  @p{««}Thanks for all the positive feedback! @p{»»}

  @p{««}And ribuck's right@p{--} when I first started putting together the
  talk there were about 5 million bitcoins worth about 2.5 million
  dollars. @p{»»}

  @p{««}By the time I gave it, they were worth about 4 million dollars. And
  two days after I gave it bitcoins hit $US 1.00 ... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0574}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-16 16:03:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3426.msg49820@s{hash}msg49820
@section 3 {tx}

  @p{««}Huh. @p{»»}

  @p{««}I live next to a major research university, and at least around
  here people get PAID to participate in psychological experiments. @p{»»}

  @p{««}Not the other way around. @p{»»}

  @p{««}So I guess my short answer would be "no". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0575}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-16 20:26:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3517.msg49939@s{hash}msg49939
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure. sirius: after getting the 0.3.20 release out, I want to work
  with you (and everybody else) to make the bitcoin.org website more
  newbie-friendly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0576}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-16 20:41:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3514.msg49946@s{hash}msg49946
@section 3 {tx}

  @p{««}Update on the problem and release: @p{»»}

  @p{««}m0mchil reports no rendering issues running a 0.3.20 bitcoin
  compiled using the mingw toolchain, and has volunteered to
  document/setup the build environment (in an Amazon EC2 virtual machine
  that I'll make public so it'll be easier for anybody to get a working
  bitcoin windows build environment up and running). @p{»»}

  @p{««}And responding to alkor: Windows/Mac open source coders seem to be
  a lot rarer than Linux... which is not surprising, I suppose. @p{»»}

  @p{««}PS to genjix: Looking good! I'll try to find some time to give it a
  try (I don't know Qt programming so I probably won't be able to help
  code, though). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0577}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-16 22:08:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3441.msg49982@s{hash}msg49982
@section 3 {tx}

  @s{quotedtext}

  @p{««} First, "potentially forking" changes like that would be structured
  as: @p{»»}

  @p{««}if (block number @p{lt} SOME_BLOCK_NUMBER_IN_THE_FUTURE) @p{»»}

    @p{(li}...old rules @p{li)} else @p{»»}

    @p{(li}...new rules @p{li)}

  @p{««}Assuming a super-majority of people agree with the change and
  upgrade before we get to SOME_BLOCK_NUMBER_IN_THE_FUTURE, the switch
  will happen smoothly. @p{»»}

  @p{««}Is there a chance of changing? Sure, but I think anybody who wants
  to make such a fundamental change would need to do a LOT of
  testing@p{--} maybe spin up or recruit a few hundred machines all over
  the world on a test network, have them mine and simulate transactions to
  each other (ideally with similar volume to the real network) while going
  through the transition and making sure there weren't any unintended
  consequences. And convince a super-majority of people that the benefit
  of their potentially forking change outweighs the risk of disrupting the
  network if there's some consequence they didn't think of or that their
  test network didn't simulate properly. @p{»»}

  @p{««}Practically, would dropping the block time from 10 minutes to 1
  minute be worth the risk? I doubt it. 1-10 minutes (1 would be the
  average, get unlucky and it could take 10) is still too long to wait for
  small-value in-person transactions. @p{»»}

  @p{««}RE: democratic organ: bitcoin is a kind of a democracy. Whatever
  code the majority of miners/nodes is running makes the rules. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0578}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-17 00:16:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=218.msg50046@s{hash}msg50046
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, but there should be. @p{»»}

  @p{««}Proposal: treat immature coins as starting with -100 confirmations,
  and modify listtransactions to list immature category=generate coins
  (with negative confirmations). @p{»»}

  @p{««}There's probably an off-by-one-error lurking there... (will have to
  make sure the coinbase transaction is spend-able when it goes from -1 to
  0 confirmations). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0579}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-17 21:01:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3553.msg50416@s{hash}msg50416
@section 3 {tx}

  @p{««}The linux binaries are built on Ubuntu 9.04; that's the earliest
  ubuntu that has all the required dependencies. @p{»»}

  @p{««}Ubuntu and Debian are kissing cousins; Debian 5 would be a good
  choice if they don't have an Ubuntu that's more recent than 8.10. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0580}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-18 17:50:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1034.msg50868@s{hash}msg50868
@section 3 {tx}

  @p{««}I just committed (to git and svn) an updated build-msw.txt @p{brk}
  Thanks to m0mchil for putting together a working windows/mingw build
  environment. @p{»»}

  @p{««}And I'll be making the 0.3.20 build environment virtual machines
  (for Windows, Linux32, and Linux64, in the Amazon EC2 cloud) public,
  hopefully, if all goes well, later today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0581}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 00:14:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3612.msg51046@s{hash}msg51046
@section 3 {tx}

  @p{««}I've made public the windows, linux32 and linux64 Amazon Machine
  Images used to build bitcoin 0.3.20. If you have an Amazon EC2 account,
  you can launch them and have your own working build environment for
  linux or windows bitcoin (paid for by the hour). @p{»»}

  @p{««}They are: @p{»»}

    @p{(li}ami-4adf2c23 32-bit Linux (Ubuntu 9.04) @p{li)}

    @p{(li}ami-12df2c7b 64-bit Linux (Ubuntu 9.04) @p{li)}

    @p{(li}ami-7a21d213 Windows (with MinGW) @p{li)}

  @p{««}All created in the us-east-1b zone (I don't know if Amazon
  automatically migrates public AMIs across the world). @p{»»}

  @p{««}After launching the Linux VMs, you login as root (using the ssh
  keypair you specify when you launch). @p{»»}

  @p{««}After launching the Windows VM, you connect via Remote Desktop and
  then login as Administrator, password "bitcoin development" (you should
  change that for your instance as soon as you login, of course). @p{»»}

  @p{««}They contain bitcoin, bitcoind, and everything needed to build
  them, already built. You could launch instances and try to generate
  coins, but that's not cost-effective. @p{»»}

  @p{««}(Updated 22 Feb with 0.3.20.01 Windows AMI)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0582}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 00:16:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3473.msg51047@s{hash}msg51047
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've generated lots of blocks on the new -testnet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0583}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 00:21:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3473.msg51051@s{hash}msg51051
@section 3 {tx}

  @p{««}Version 0.3.20.01 is now at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Differences with the first release candidate 0.3.20: @p{»»}

  @p{(li}  Windows built with mingw instead of Visual C++ (my fingers are
  crossed that fixes the rendering issue)  @p{li)}

    @p{(li}@p{(li} Fix for a denial-of-service attack reported in IRC
    @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0584}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 13:36:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3623.msg51296@s{hash}msg51296
@section 3 {tx}

  @p{««}The only thing stopping me from announcing 0.3.20 "Final!" is
  confirmation from Windows users that switching to the mingw build
  process fixed the rendering issues. @p{»»}

  @p{««}So: if you're a Windows bitcoin user, please install the latest
  0.3.20 from SourceForge and let me know how it works for you. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0585}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 17:48:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3603.msg51416@s{hash}msg51416
@section 3 {tx}

  @p{««}Frankly, I'm not sure how I feel about this. @p{»»}

  @p{««}I absolutely positively want more scrutiny of both bitcoin's source
  code and the underlying cryptographic concepts. @p{»»}

  @p{««}However, I don't think offering a token amount of money (even in
  the form of bitcoins) is appropriate. @p{»»}

  @p{««}A real, professional security review of bitcoin would take a lot of
  time and a lot of money. I understand that's not what is being asked,
  but asking Mr. Schneier to write about bitcoin is really an irrational
  "Appeal to Authority" @p{--} I think he'd say that any
  cryptography-related technology is never proven secure, but only gains
  trust by having multiple people and groups of people look at it, imagine
  potential attacks, try to attack it, etc. @p{»»}

  @p{««}Or, in other words, if he writes an article about bitcoin now I
  think the summary would be "interesting new technology, doesn't appear
  to be a scam, worth keeping an eye on." I think he'll write that article
  soon without any prompting from "the bitcoin community," just given the
  level of buzz bitcoin is generating the last month or two. I don't think
  a few hundred bitcoins will motivate him to write the article any
  sooner. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0586}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 17:53:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3623.msg51422@s{hash}msg51422
@section 3 {tx}

  @s{quotedtext}

  @p{««} Did you get a debug alert with bitcoin 0.3.19 or earlier? @p{brk}
  And could you post a screen snapshot (or, even better, file an issue at
  @s{(link)} )?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0587}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 18:20:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1034.msg51447@s{hash}msg51447
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, it is public Amazon ami-2edd2e47 named
  982440761210/BitcoinMinGW @p{»»}

  @p{««}The linux32 and linux64 amis I used to build the linux releases are
  also public. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0588}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 20:12:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3462.msg51525@s{hash}msg51525
@section 3 {tx}

  @s{quotedtext}

  @p{««} 1 petabyte is 10^(15) bytes. @p{»»}

  @p{««}There are 2^(160) possible BTC addresses, each of which is 160 bits
  == 20 bytes long. @p{»»}

  @p{««}So to store all of them you need 2^(160)x20 bytes, which is
  29,230,032,746,618,058,364,073,696,654,325,660 petabytes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0589}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-19 21:58:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3462.msg51567@s{hash}msg51567
@section 3 {tx}

  @s{quotedtext}

  @p{««} There are approximately 2^(160) things higher on the development
  priority list. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0590}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-20 04:18:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3647.msg51720@s{hash}msg51720
@section 3 {tx}

  @p{««}Can you post examples of requests/responses with the "old" JSON-RPC
  and your new JSON-RPC? @p{»»}

  @p{««}I'm still firmly against this change@p{--} it seems to me you are
  "solving" a non-problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0591}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-20 15:03:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1034.msg51857@s{hash}msg51857
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, I have the VC10 VM. I am hesitant to make it publicly
  available because it has a copy of Visual C++ 2010 Express installed,
  and I don't want Microsoft to sue me for redistributing their software
  without permission. @p{»»}

  @p{««}I'll uninstall it from the VM and then make the image public;
  you'll have to download and install (and agree to the license) Visual
  Studio Express yourself to get it working. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0592}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-20 18:35:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1034.msg51955@s{hash}msg51955
@section 3 {tx}

  @p{««}Here's the public AMI for the dodgy 0.3.20 VC10 build: @p{»»}

    @p{(li}ami-d621d2bf 982440761210/BitcoinVC10 @p{li)}

  @p{««}Bitcoin source is at c:\bitcoin @p{brk} (all the other dependencies
  are in the root c:\, too). @p{brk} Administrator password is: bitcoin
  development @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0593}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-20 22:49:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3638.msg52078@s{hash}msg52078
@section 3 {tx}

  @s{quotedtext}

  @p{««} CSV file with the private key and block numbers is a good idea,
  although for it to be a valid CSV file then it needs to have a fixed
  number of columns. @p{»»}

  @p{««}I'd modify the design slightly to be just: @p{brk} base58 encoded
  privkey,block number @p{brk} ... where block number is the block number
  of the earliest input (that'll save rescanning time@p{--} you probably
  always want to rescan from the earliest block number, anyway, in case
  more payments were sent after you exported the key). @p{»»}

  @p{««}Also what do you mean by "export" @p{--} write and then remove the
  keys from the wallet? Write a newly generated key and generate a
  payment-to-that-key for a given amount of coins? @p{»»}

  @p{««}I think any code that removes keys from the wallet (or generates
  payments to keys that are never added to the wallet) needs to be
  structured as two distinct steps: @p{brk} 1. Write the keys to
  @p{lt}destination@s{gt} @p{brk} 2. Read @p{lt}destination@s{gt} to make
  sure it is valid, and, if it is, delete the corresponding keys from the
  wallet (or generate the send-to-self txn). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0594}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 01:05:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3641.msg52144@s{hash}msg52144
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. @p{»»}

  @p{««}Patches welcome, as long as they're nice and stable and have had a
  fair bit of testing... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0595}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 05:03:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3681.msg52236@s{hash}msg52236
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. You should expect the testnet to be reset, if for no other
  reason than to keep people from using it as a "real" currency. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0596}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 13:26:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1034.msg52355@s{hash}msg52355
@section 3 {tx}

  @p{««}@p{(so}Oops, sorry@p{--} I forgot to change the admin password. The
  correct pw for that instance is: @p{»»}

    @p{(li}penguinsrule@p{so)} @p{li)}

  @p{««}I change the password to match the MinGW VM and updated the AMI:
  @p{»»}

    @p{(li}ami-d621d2bf 982440761210/BitcoinVC10 @p{li)} Admin password:
  bitcoin development @p{»»}

  @p{««}You should change the password as soon as you login or make sure
  you use a security group that only allows your IP address to access the
  virtual machine. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0597}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 20:52:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg52561@s{hash}msg52561
@section 3 {tx}

  @p{««}Binaries for Bitcoin version 0.3.20.01 are available at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}There were several changes and additions to the JSON
  remote-procedure-call interface; @p{brk} there are no significant user
  interface changes. See: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}msg48839@p{link)} @p{li)} ... for details.
  @p{»»}

  @p{««}This version does fix one significant denial-of-service attack
  (earlier versions of @p{brk} bitcoin could be caused to crash due to
  running out of memory by a remote @p{brk} attacker). @p{»»}

  @p{««}SHA1-checksums for the binary files are: @p{brk}
  bitcoin-0.3.20-linux.tar.gz 7dfbc05b36112f59886a29f044cfd21c6c253169
  @p{brk} bitcoin-0.3.20-win32-setup.exe
  2a4affd92dd11e0b759f90a8fa4bead58bdbf7b4 @p{brk}
  bitcoin-0.3.20-win32.zip 7bf306554092e742d076d4157aaa077d95de6102
  @p{brk} bitcoin-0.3.20-macosx.zip
  47ca28454e7ea0b576b80905353d1cea024e53fe @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0598}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 21:56:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg52627@s{hash}msg52627
@section 3 {tx}

  @p{««}First: the bitcoin.org homepage links will be updated as soon as
  sirius has a chance to wake up, read his email, and make the changes.
  @p{»»}

  @s{quotedtext}

  @p{««} A different skin for the Windows build is from upgrading the
  wxWidgets used to build (2.9.1 instead of 2.9.0). @p{»»}

  @p{««}Did anybody test the -nolisten with the GUI bitcoin on Windows?
  @p{brk} I believe there is windows-specific code for checking to see if
  another bitcoin is running that looks at window titles; file an issue at
  github if -nolisten isn't doing what you expect. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0599}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-21 23:39:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg52710@s{hash}msg52710
@section 3 {tx}

  @s{quotedtext}

  @p{««} Did I put the wrong bitcoin@p{(bf}d@p{bf)}.exe in the Windows exe
  and/or zip? @p{»»}

  @p{««}D'oh! @p{»»}

  @p{««}Companies I've worked for in the past had a rule@p{--} programmers
  were not allowed to test their own code. I'm still looking for people to
  volunteer to be dedicated quality assurance testers (and a quality
  assurance manager to organize them) to help keep this type of thing from
  slipping through. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0600}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-22 17:46:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg53114@s{hash}msg53114
@section 3 {tx}

  @p{««}I'll be re-releasing updated windows .zip and .exe files later
  today to fix these issues. @p{brk} And this time I'll triple-check
  versions on everything. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0601}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-22 20:29:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg53187@s{hash}msg53187
@section 3 {tx}

  @p{««}RE: a checklist: @p{»»}

  @p{««}For the next release, I will write a script that does all of the
  build/package steps. I'll let the computer run the checklist for me...
  and the whole process should be much quicker, easier and smoother. @p{»»}

  @p{««}RE: 0.3.20.01 @p{»»}

  @p{««}Fixed builds are at sourceforge, named 'bitcoin-0.3.20.01' to try
  to avoid confusion. @p{brk} The mac build was 0.3.20.00 also; I am going
  to update that .zip when we get a .01 build, and I think I'll rename the
  @p{brk} linux downloads to be consistent and, again, to try to avoid
  confusion. @p{»»}

  @p{««} SHA checksums: @p{»»}

  @p{««}3fe4c5f2a5406322a2f116b30aefbd402b079940
  bitcoin-0.3.20.01-win32-setup.exe @p{brk}
  dffb709a90a7abcff08c2ef1e79d3f9b54751786 bitcoin-0.3.20.01-win32.zip
  @p{»»}

  @p{««}The public Amazon AMI virtual machine image used to build them is:
   @p{brk} ami-7a21d213 982440761210/BitcoinMinGW @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0602}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-22 22:36:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3686.msg53248@s{hash}msg53248
@section 3 {tx}

  @s{quotedtext}

  @p{««} Rumor has it he stole an Infinite Improbability Drive.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0603}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 00:34:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3704.msg53291@s{hash}msg53291
@section 3 {tx}

  @p{««}Updated Mac build is on Sourceforge, as is a PGP-signed README.txt.
  @p{»»}

  @p{««}I also just changed the links on the front page of the wiki; the
  links at bitcoin.org will be updated as soon as sirius and I are awake
  at the same time again @s{smiley} @p{»»}

  @p{««}SHA1-checksums for the binary files are:@p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0604}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 01:35:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3759.msg53307@s{hash}msg53307
@section 3 {tx}

  @p{««}@p{(so}Looks like somebody's playing with a tweaked bitcoin@p{--}
  if you trace back the inputs they're from a previous block that has the
  same odd pattern. @p{»»}

  @p{««}The standard coin selection algorithm in bitcoin would generate a
  one input / one output transaction.@p{so)} @p{»»}

  @p{««}Hal and theymos are right@p{--} I misremembered how the coin
  selection algorithm works. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0605}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 01:47:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3686.msg53312@s{hash}msg53312
@section 3 {tx}

  @p{««}Hmmm... @p{»»}

  @p{««}Thinking a little more, Mr. Lucky will have some coding to do.
  Blocks are indexed based on their hash, so when he generates that second
  all-zero hash he's going to have trouble with the current
  implementation. Actually, he'll have trouble before then, because if the
  target is low enough there won't be enough unique hashes... @p{»»}

  @p{««}(and before somebody asks: YES, there is a very small chance that
  two blocks will be found with the same hash. And NO, that is NOT a
  problem that needs to be solved, it is so improbable it is not worth
  worrying about). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0606}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 14:34:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3759.msg53546@s{hash}msg53546
@section 3 {tx}

  @s{quotedtext}

  @p{««} "people" is me@p{--} when I tweak the Faucet's code I erase my IP
  address from its database and then have it send coins to itself as a
  sanity test. @p{»»}

  @p{««}And Hal's right, Bitcoin chooses transactions to spend, not
  specific outputs (which only matters for sends-to-self, where you own
  both outputs of a transaction). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0607}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 17:54:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3712.msg53620@s{hash}msg53620
@section 3 {tx}

  @s{quotedtext}

  @p{««} Our legal systems haven't caught up with the Internet. What's the
  proper jurisdiction for somebody in Iceland using a bitcoin exchanger in
  the US who got ripped of by somebody living in (lets see, which country
  do I want to offend today....) a seasteading community? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0608}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 18:50:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3770.msg53658@s{hash}msg53658
@section 3 {tx}

  @p{««}Bitcoin is confusing at first glance because so many problems are
  solved using just a few ideas. If you think about it long enough, it is
  quite elegant. @p{»»}

  @p{««}The busy-work of finding a block hash that is "small enough" solves
  a couple of problems: @p{»»}

  @p{««}First, by making it hard to create coins so they are artificially
  scarce. That is really important; if it was easy to create gazillions of
  bitcoins we'd all have gazillions of bitcoins that were worth nothing.
  @p{»»}

  @p{««}Second, it solves the double-spending problem@p{--} the computer
  that solves the busy-work problem first gets to decide which
  transactions are "THE" transactions, and which ones are invalid (because
  you're trying to spend coins you've already spent). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0609}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 21:37:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg53770@s{hash}msg53770
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}This modifies FormatMoney to display full-precision values (with
  trailing zeroes trimmed correctly@p{--} e.g. 0 is 0.00 but 0.00010000
  displays as 0.0001). @p{»»}

  @p{««}And ParseMoney allows entry of full-precision values. @p{»»}

  @p{««}And JSON's AmountFromValue doesn't round to two places, so you can
  send/move full-precision values. @p{»»}

  @p{««}I haven't tested this with the GUI bitcoin yet, it will probably
  require UI layout tweaks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0610}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-23 21:53:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg53776@s{hash}msg53776
@section 3 {tx}

  @p{««}I just did some testing (on Linux) and the GUI seems to handle
  full-precision values quite nicely. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0611}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-24 02:39:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg53946@s{hash}msg53946
@section 3 {tx}

  @s{quotedtext}

  @p{««} Converting from a double-precision float from the JSON library to
  an int64 bitcoin is: @p{»»}

  @p{««}Code: int64 nAmount = roundint64(dAmount * COIN); ... which will
  always do the right thing (COIN is 100000000). @p{»»}

  @p{««}int64 to JSON string there are no code changes. @p{»»}

  @p{««}GUI string to int64 is a direct conversion, no intermediate double
  precision. @p{»»}

  @p{««}And int64 to GUI string is: @p{»»}

  @p{««}Code: strprintf("%.08f", double(amount)/double(COIN)) ... which
  also always does the right thing (printf of a floating point number
  rounds, and there is enough precision in a double the rounding will
  always be correct). @p{»»}

  @p{««}0.1 bitcoins will always become exactly 10000000 base units
  internally, and 10000000 base units will always be shown as exactly 0.10
  (in the GUI) or 0.10000000 (in JSON). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0612}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-24 03:58:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3693.msg53991@s{hash}msg53991
@section 3 {tx}

  @s{quotedtext}

  @p{««} Entering a password every time you want to send coins (or pulling
  out your... dongle... err, that didn't come out right, uhh, fetching
  your one-time-password-generating-device) might be annoying enough that
  withdrawing 50 or 100 bitcoins that you can spend with minimal hassle
  would be a nice feature. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0613}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-24 04:17:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3805.msg54006@s{hash}msg54006
@section 3 {tx}

  @p{««}From another thread: @p{»»}

  @s{quotedtext}

  @p{««} No need to embed the identification in the transactions, I don't
  think. You just need to associate your public keys with 'you' at some
  place where anybody can see that association and prove that you
  originally owned the private keys associated with those public keys.
  @p{»»}

  @p{««}Let's see, I think something like this would work: @p{»»}

  @p{««}For every private key in your wallet: @p{»»}

    @p{(li}Grab the corresponding public key @p{li)}

    @p{(li}Sign it with the private key @p{li)}

    @p{(li}Compute SHA256(public key, signature, "your name and email
    address") @p{li)}

  @p{««}Then upload all of those SHA256 hashes to some secure central
  database somewhere, which stores it along with the time it was uploaded.
  @p{»»}

  @p{««}Now if somebody copies your wallet and spends your coins, you can
  prove that you had the public/private keys in the past by showing
  everybody the (public key, signature, "your name and email address")
  that hashes to the value in the central database. @p{»»}

  @p{««}The crook can upload their own SHA256, of course@p{--} this relies
  on you uploading before the crook.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0614}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-25 19:59:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3840.msg55155@s{hash}msg55155
@section 3 {tx}

  @p{««}Yes, not implemented yet. Do you want to remove them just so the
  listaccounts output isn't messy, or is the lack of a deleteaccount API
  call preventing you from doing something you need to do? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0615}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 16:09:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3805.msg55591@s{hash}msg55591
@section 3 {tx}

  @p{««}RE: trading private keys with somebody: theoretically you could,
  but that's not typical bitcoin usage and the current bitcoin client
  makes it hard to do. @p{»»}

  @p{««}Practically speaking, if Bitcoin did have a feature to state:
   @p{brk} "On THIS date somebody using the identifier
   @s{code} controlled THIS public/private keypair" @p{»»}

  @p{««}... that would just inspire the smarter bad guys to send stolen
  coins to new private keys before spending them. @p{»»}

  @p{««}I can imagine a black market forming where dumber bad guys sell
  stolen wallet.dat files (at a discount) to smarter bad guys (or just
  plain greedy people who don't bother to ask where the wallet came from),
  who mix up the coins in them and then sell them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0616}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 17:25:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3903.msg55623@s{hash}msg55623
@section 3 {tx}

  @p{««}I'm looking for feedback and suggestions for a new ClearCoin
  feature: refund-to-charity @p{»»}

  @p{««}Here's how it works: @p{»»}

  @p{««}When Alice creates an escrow account at ClearCoin she says that, if
  the coins in the account are not released, they'll be donated to
  charity. @p{»»}

  @p{««}She then funds the account, and shows Bob (the person she's trading
  with) that the coins are sitting in escrow. @p{»»}

  @p{««}Alice knows that if Bob doesn't complete the trade he won't get the
  coins. @p{brk} Bob knows that if Alice doesn't release the coins she
  won't get them either. @p{»»}

  @p{««}So neither Alice nor Bob has a strong incentive to cheat. They each
  have a weak incentive if they'd rather the charity get the coins (and
  they're not worried about potential harm to their reputation). @p{»»}

  @p{««}I've got an initial implementation up and running, with the list of
  charities from the Bitcoin wiki Trade page. @p{brk} I'm thinking of a
  few enhancements, and would love feedback on which ones you think are
  critical and which would be just nice-to-have: @p{»»}

    @p{(li} 1. Give Bob (the person receiving the coins) a way to setup
  the escrow and send a link to Alice (who controls the account). @p{brk}
  2. Let Bob and Alice agree (in advance) to refund the bitcoins to an
  arbitrary address instead of a fixed list of charities. @p{brk} 3. If
  the coins are refunded to charity, show Alice and Bob the transaction ID
  so it is easier for them to make sure ClearCoin isn't taking the coins.
  @p{li)}

  @p{««}General feedback, criticism, etc. is also very welcome! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0617}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 18:01:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3876.msg55638@s{hash}msg55638
@section 3 {tx}

  @p{««}I've been thinking a lot and trying to educate myself on best
  practices for securing the bitcoin wallet. @p{»»}

  @p{««}Part of the solution could be a smart card that supports ECDSA; the
  @p{(link}PKCS @s{hash}11 standard@p{link)} supports elliptic key crypto, so it
  is feasible to have a hardware token that stores your private keys and
  never lets them out of the token. @p{»»}

  @p{««}If the token includes some type of biometric identification (e.g.
  built-in fingerprint reader or mechanism for entering a password) then
  there is no way for the trojan to spoof new transactions. @p{»»}

  @p{««}But (mike) is right@p{--} if your computer is infected by a trojan
  the trojan can just rewrite the bitcoin address and amount before the
  software asks the hardware token to sign the payment transaction. The
  only way to prevent that is if the hardware token can somehow display
  the transaction details independent of the infected computer. That's one
  very sophisticated hardware token... @p{»»}

  @p{««}Hopefully Hal and bitcoinex will now tell us how all this was
  solved years ago and how an iPhone app synchronized with a dumb-ish
  smart card can use smart crypto to make it all work.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0618}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 22:02:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3906.msg55707@s{hash}msg55707
@section 3 {tx}

  @p{««}What happens if: @p{»»}

    @p{(li} you dump a private key from bitcoin client 'A' @p{li)}

    @p{(li} @p{--} shutdown A @p{li)}

    @p{(li} @p{--} import it into bitcoin client 'B' @p{li)}

    @p{(li} @p{--} spend it from B @p{li)}

    @p{(li} ... wait for a confirmation or three... @p{li)}

    @p{(li} @p{--} restart A @p{»»}

  @p{««}Does A notice that the coin's been spent? I think there's a bug
  that it does not, and I think that bug needs to be fixed before we make
  it easy to export/import private keys. So, please bang on sipa's patch
  and see if anything else breaks! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0619}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 22:11:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3876.msg55708@s{hash}msg55708
@section 3 {tx}

  @s{quotedtext}

  @p{««} Uh-huh... storing a lot of bitcoins on a usually-network-connected
  device would make me very nervous. I think we're going to see a LOT of
  smartphone exploits over the next 5 years (maybe I'll be pleasantly
  surprised and it will turn out the smartphone OS folks have done a great
  job making them secure). @p{»»}

  @p{««}But security is not a boolean, and we clearly need to do what we
  can to help people keep their bitcoin wallets secure. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0620}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-26 22:34:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3903.msg55718@s{hash}msg55718
@section 3 {tx}

  @s{quotedtext}

  @p{««} Great suggestion, I will modify the code to refund the escrow fee
  (if any) and donate the rest. @p{»»}

  @s{quotedtext}

  @p{««} I have some preliminary plans for mediated escrows that will
  require all three parties to have ClearCoin accounts. I'm still thinking
  about how to make it as simple to use as possible. @p{»»}

  @s{quotedtext}

  @p{««}Great idea, I'll put it on the "nice to have" list. @p{»»}

  @s{quotedtext}

  @p{««}Easy to do. How critical is time? Plus or minus 1 hour would be
  easy (there's a 'cron job' that runs once per hour to process refunds),
  but I don't want to make the Create an Escrow page more complicated than
  it really needs to be. @p{»»}

  @s{quotedtext}

  @p{««}I'll probably target transactions under $50 remaining free, and I'm
  thinking of capping fees at $4... but it is likely I'll experiment with
  different pricing models as I fill out features. Paying mediators
  (before and/or when mediation is required) adds lots more wrinkles...
  @p{»»}

  @s{quotedtext}

  @p{««}Nope. Maybe I'll franchise later if Bitcoin and ClearCoin really
  take off. @p{»»}

  @s{quotedtext}

  @p{««}No@p{--} what authentication method would you like to see? I don't
  like the idea of supporting arbitrary OpenID authentication, because it
  is so easy to create throwaway OpenID identities (creating throwaway
  Google identities is at least a LITTLE bit harder...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0621}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-27 00:29:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3918.msg55772@s{hash}msg55772
@section 3 {tx}

  @p{««}See: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The exact hash done is double-sha256:
  sha256(sha256(block_header_data)) @p{brk} See: @p{brk} @s{(link)} @p{»»}

  @p{««}... for information about sha256 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0622}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-27 20:16:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3933.msg56232@s{hash}msg56232
@section 3 {tx}

  @s{quotedtext}

  @p{««} Saving for the future: bitcoins are designed to be like gold:
  durable, only a limited supply. They have some advantages over
  gold@p{--} they're much easier to store safely (you don't have to buy a
  bank vault or hire guards or trust a storage company) and, because
  they're electronic, they can be backed up. And when it is time to sell
  them the transaction costs are very, very low. @p{»»}

  @p{««}Buy some goods online: I don't think bitcoins have any significant
  advantage... yet. Transaction fees are lower once you get bitcoins, but
  the transaction fees to get bitcoins probably eliminate that advantage.
  @p{»»}

  @p{««}I think Bitcoin's real, hidden advantage is the fact that you don't
  have to ask anybody's permission or fill out any paperwork to start
  doing creative, innovative things with them. Lots of people are doing
  lots of innovative things with bitcoins, and while most of those
  innovative things will probably fail (most startups fail), I'm
  optimistic that some will succeed and in 5 years we'll be using bitcoins
  in some way we haven't even imagined yet. I'm not going to pretend to
  know which market niches bitcoin will fill@p{--} maybe it will be
  migrant workers using bitcoin to send money back home and avoiding
  international wire transfer and currency conversion fees. @p{»»}

  @p{««}Maybe teenagers in China will use them to buy stuff online because
  they can't get a credit card. @p{»»}

  @p{««}Maybe big multinational corporations will decide to use bitcoins to
  pay their supply chain to avoid currency exchange risk and save 0.1% on
  their transactions. Who knows? Even if bitcoin turns out to be just "a
  better store of value than gold" it will be hugely successful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0623}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-27 21:15:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3933.msg56262@s{hash}msg56262
@section 3 {tx}

  @s{quotedtext}

  @p{««} JollyGreen was asking about 'typical people'. And I think he was
  asking about "right now". @p{»»}

  @p{««}Typical people aren't going to distinguish the currency from all of
  the financial services that make the currency safe, convenient, etc. And
  I think we should be honest@p{--} bitcoin-the-currency needs more mature
  financial services before bitcoin-the-system makes sense as a payment
  solution for typical people. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0624}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 02:56:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3947.msg56484@s{hash}msg56484
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. Generated coins need a place to go (they're credited to the ""
  account), and coins you send using sendtoaddress (where you don't
  specify an account) need to be debited from somewhere (they're debited
  from the "" account). @p{»»}

  @p{««}And it's theoretically possible somebody might could use one of
  your hidden "change" bitcoin addresses to send you coins; they'd be
  credited to the "" account, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0625}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 12:48:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3958.msg56666@s{hash}msg56666
@section 3 {tx}

  @p{««}The official client uses an older version of Berkeley DB (4.8,
  according to build-osx.txt). @p{»»}

  @p{««}You're linking to Berkeley DB 5.1.19, so when you run your client
  it upgrades the bitcoin database files, which makes them incompatible
  with the official client. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0626}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 18:29:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg56851@s{hash}msg56851
@section 3 {tx}

  @s{quotedtext}

  @p{««} Can anybody else reproduce this? It works for me: @p{brk}
  @s{image} 

# ----------------------------------------------------------------------
@section 2 {ms0627}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 19:32:30 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2172.msg56879@s{hash}msg56879
@section 3 {tx}

  @p{««}Are you setting the ContentType as described here: @p{»»}

    @p{(li}@p{(link}@s{(link)}(JSON-RPC)@s{hash}.NET_(C_)@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0628}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 19:33:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3970.msg56880@s{hash}msg56880
@section 3 {tx}

  @s{quotedtext}

  @p{««}So? So?!? 11 is my favorite number! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0629}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 21:38:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg56968@s{hash}msg56968
@section 3 {tx}

  @p{««}It was LC_NUMERIC, I bet... (I'd just set LANG and unset the rest
  and assumed they'd all get picked up; internationalizing C++
  applications is something I know very little about). @p{»»}

  @p{««}I modified the patch to format numbers the way they were formatted
  before: always , for the thousands separator, and . for the decimal
  point (instead of letting sprintf try to do the right thing). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0630}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-02-28 22:48:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3971.msg57029@s{hash}msg57029
@section 3 {tx}

  @p{««}80 transactions per second is 6.9 million transactions per day.
  That is a LOT. @p{»»}

  @p{««}PayPal was doing @p{(link}about 2 million transactions per
  day@p{link)} in 2008; if there are three times as many bitcoin
  transactions as PayPal transactions in a few years that would be a very
  good problem to have, and I'm confident "we" would figure out how to
  deal with lots of transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0631}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 01:00:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3786.msg57097@s{hash}msg57097
@section 3 {tx}

  @s{quotedtext}

  @p{««} I was tempted to do more than fix the rounding problem... @p{brk}
  ... but then sanity overwhelmed me. @p{»»}

  @p{««}If you'd like to start a discussion of whether or not it is a good
  idea for one-thousand German bitcoin amounts to be displayed as
  "1.000,00", be my guest. I think there was such a discussion in the
  past, but I didn't pay attention to it. I think it would be nice if an
  amount like "1.001 BTC" (or even "1.001 tonal bitcoins") was
  unambiguous. @p{»»}

  @p{««}RE: subcent throwaway change: turn it into a proper PULL request
  (yes, you'll have to@p{--} horrors! @p{--} use that evil, not
  100%-pure-open-source github) and it'll happen faster. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0632}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 15:10:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2772.msg57453@s{hash}msg57453
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good Idea. You should do that. Maybe marking issues at github with
  a "Launchpad" tag would be a good system? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0633}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 15:12:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3999.msg57456@s{hash}msg57456
@section 3 {tx}

  @s{quotedtext}

  @p{««}Actually, I'm considering turning on transaction fees for the
  Bitcoin Faucet because small transactions with "new" coins are given
  very low priority, and recently new users are noticing that their Faucet
  coins are not arriving promptly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0634}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 15:39:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4009.msg57469@s{hash}msg57469
@section 3 {tx}

  @p{««}This is: @s{(link)}@s{hash}issue/86 @p{»»}

  @p{««}currently (2011/03/01) a backlog of transactions that dont seem
  make it into blocks is building up (according to ArtForz now 670
  transactions). @p{»»}

  @p{««}People are starting to complain, see
  @p{(link}@s{(link)}@s{hash}msg57031@p{link)} for an example. @p{»»}

  @p{««}This was discussed on @s{hash}bitcoin-dev @p{»»}

  @p{««}ArtForz@s{gt} that tx should have a score of 20567855 @p{li)}

  ArtForz@s{gt} so it falls short of the dPriority @s{gt} COIN * 144 / 250
  test @p{li)}

  ArtForz@s{gt} and as tx size is @s{gt} 4000, fAllowFree is never true
  for it @p{li)}

  theymos@s{gt} Ah. So it will never confirm? @p{li)}

  ArtForz@s{gt} probably not @p{»»}

  @p{««}ArtForz@s{gt} looks like the tx-sending code needs some fixing
  @p{li)}

  molecular@s{gt} like not generate a tx with a score too low, or suggest
  to add a fee? @p{li)}

  ArtForz@s{gt} yep @p{li)}

  ArtForz@s{gt} check size and priority of transaction, if it's @s{gt} 4kB
  and score @p{lt} 57600000 require min fee @p{li)}

  ArtForz@s{gt} maybe reduce the size limit to 3.5k or so, otherwise it
  can only get into an otherwise empty block @p{»»}

  @p{««}Maybe the transaction cache should not be unlimited? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0635}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 16:02:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4009.msg57481@s{hash}msg57481
@section 3 {tx}

  @p{««}This definitely needs fixing; it is another "people getting lots of
  very small change from mining pools" issue. @p{»»}

  @p{««}The code that controls this is CTransaction::GetMinFee() in main.h
  and CreateNewBlock() in main.cpp. @p{»»}

  @p{««}We should think about: @p{»»}

  @p{(li}  Is setting aside a specific amount of space for free transactions
  the right thing to do? Maybe blocks should just get filled in reverse
  priority order (with transactions with fees at the front of the line)
   @p{li)}

  @p{(li}  What to do with the current transaction backlog. @p{brk} If old,
  big, low-priority transactions get flushed, then there needs to be some
  way for the bitcoin client(s) that sent them to reclaim those coins.
  Perhaps the client should stop retransmitting, and reclaim, transactions
  if, oh, 5,000 blocks go by without the transaction getting accepted.
   @p{li)}

  @p{««}Or maybe it makes sense to let those old transactions trickle in;
  perhaps the next version of bitcoin should take the oldest transaction
  in the memory cache and add it to the generated block.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0636}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 18:07:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4009.msg57562@s{hash}msg57562
@section 3 {tx}

  @s{quotedtext}

  @p{««} You can generate a 1MB block with only free transactions in it and
  it will get accepted (maximum block size is 1MB, although the standard
  bitcoin client will never generate blocks larger than 500K). @p{»»}

  @s{quotedtext}

  @p{««} The problem isn't the pool payout@p{--} the problem is that people
  participating in the pool end up with wallets full of tiny (e.g.
  penny-size) transactions. When they go to spend those tiny transactions,
  they're bundled up together to make a transaction that is small in value
  but large in size. @p{»»}

  @p{««}Pools can mitigate the problem by requiring larger minimum payouts
  (e.g. 1 BTC instead of 0.01 BTC). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0637}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 18:28:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3980.msg57576@s{hash}msg57576
@section 3 {tx}

  @p{««}Thanks for the donations, everybody! @p{»»}

  @p{««}Catching up on questions: @p{»»}

  @p{««}Is the faucet supported entirely by donations? Not entirely@p{--}
  the captchas have generated about $100, which will go into refilling it.
  It looks like captcha revenue is only covering about 1/4 of the cost of
  the coins, although the company that does the money-for-captchas is a
  startup looking for more advertisers. Actually, if you want to advertise
  a bitcoin-related business you should talk to them... (they're
  adscaptcha.com) @p{»»}

  @p{««}Was somebody abusing the faucet? Yep, somebody was exploiting a
  weakness in my IPv6-handling code. I've fixed the weakness (the faucet
  is now much stricter about what it considers "different" IPv6
  addresses), but I think I'm fighting a losing battle@p{--} the next step
  will be to require you to login with a valid google account to get
  coins. I hate to add another hoop to jump through... @p{»»}

  @p{««}Is it time to reduce the payout? Maybe soon, but I'd rather wait
  until the next release is out and then reduce the payouts another factor
  of 10 (so 'standard' payout if balance was above 500BTC would be
  0.05BTC, and 0.005 when it was running low). @p{»»}

  @p{««}Can I add a link to bitcoinmonitor.com? Done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0638}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 19:51:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3999.msg57637@s{hash}msg57637
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. The only way to "break your stash" is to create transactions
  that are broadcast; splitting your wallet into lots of small
  transactions makes the problem worse for you and everybody else (it is
  more 'expensive' to handle fistfulls of nickels and pennies, even in the
  bitcoin world). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0639}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-01 22:02:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4009.msg57757@s{hash}msg57757
@section 3 {tx}

  @p{««}RE: limitfreerelay: @p{»»}

  @p{««}Agreed, that's better. I think we should start soft-coding the
  amount that is considered "free" instead of hard-coding CENT, and make
  the default less than 0.0001 BTC. @p{»»}

  @p{««}Separate subjects: @p{»»}

  @p{««}The entire transaction memory pool should be size-limited, with
  lower-priority transactions dropped. @p{»»}

  @p{««}I agree with Steve@p{--} free transactions are a HUGE selling
  point, and I think rational miners should realize that their bitcoins
  will be more valuable if there are more users. And there will be more
  users if "free transactions" is a feature. I think we can come up with a
  solution where "normal" transactions are free, but spam or abnormally
  complicated transactions (yes, like those bitpenny rewards pooled mining
  participants are currently getting once a day) "require" a fee (where
  "require" is really "if you don't include a fee your transaction will
  probably never be confirmed.") @p{»»}

  @p{««}And finally... we've got a problem right now; lets think about what
  fix(es) move us in the right direction quickly, or think about fixes
  that will solve the current problem (that we may need to undo/rework
  later). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0640}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-02 00:21:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4034.msg57843@s{hash}msg57843
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've got a (private so far) patch that creates mass-pay
  transactions. API is: @p{»»}

    @p{(li}sendmulti @p{lt}fromaccount@s{gt} {address:amount,...}
    (minconf=1) (comment) @p{li)}

  @p{««}This code in CTransaction::AcceptToMemoryPool will need to change,
  too: @p{»»}

  @s{code}

    @p{(li} return error("AcceptToMemoryPool() : nonstandard
  transaction"); (a mass-pay transaction will have N+1 OP_CHECKSIGs in it,
  where N is the number of people being paid). @p{»»}

  @p{««}Replacing in the stock client with something like: @p{»»}

  @p{««}Code: if (GetSigOpCount() @s{gt} 2) minFee +=
    GetSigOpCount()*GetArgMoney("-masspayfee", CENT/100); ... seems like
    the right direction to go. @p{»»}

  @p{««}BUT: I think a higher priority is figuring out how to deal with
  fees for the other two send methods.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0641}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-02 16:50:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2953.msg58308@s{hash}msg58308
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... and you get 'fatal error, can't create' when you try to
  compile bitcoin? @p{»»}

  @p{««}Sounds like your obj/ dir is not writeable by whichever user you're
  using to compile. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0642}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-02 21:36:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4064.msg58529@s{hash}msg58529
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}This makes CTransaction::CreateTransaction use the same rules for
  what transactions require a fee as CBlock::CreateBlock. @p{»»}

  @p{««}The mismatch was the root cause of the transaction slowness
  (low-priority free transactions were created but weren't being included
  into blocks until they 'matured' and had a higher priority). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0643}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-02 23:18:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3977.msg58574@s{hash}msg58574
@section 3 {tx}

  @p{««}If there is a virus on your computer, and your bitcoins are stored
  on that computer, then there is nothing the bitcoin software can do to
  prevent that virus from eventually stealing your coins. @p{»»}

  @p{««}That said, allowing you to 'lock' your coins with a password, and
  requiring that you enter that password to send coins, is high on the
  list of things I'd like to see bitcoin do. That would make it harder for
  a virus to steal your coins. @p{»»}

  @p{««}But even then, a smart virus could lay in wait until you typed your
  password to unlock your wallet and take that opportunity to either
  capture your password or send the coins to a bad guy. If you can't trust
  your computer, don't store your life savings on it (and yes, bitcoin
  software also should make it easy to save some of your bitcoins on USB
  sticks or CD-R disks so they can be stored safely in your safe deposit
  box at your bank). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0644}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 13:15:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg58852@s{hash}msg58852
@section 3 {tx}

  @p{««}Because JavaScript doesn't have a 64-bit integer type (all Numbers
  in JavaScript are double-precision floating point).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0645}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 13:33:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg58861@s{hash}msg58861
@section 3 {tx}

  @p{««}Can we not beat this dead horse? @p{»»}

  @p{««}I think there are MUCH more important things to work on / worry
  about than whether or not "send 1 BTC" is expressed as "sendtoaddress
  FOO 1.00" or "sendtoaddress FOO 100000000" in the JSON-RPC. @p{»»}

  @p{««}How about we (I'll start) write a "Proper Money Handling" page for
  the Wiki that discusses the issue and gives code example of how to
  convert to/from JSON double-precision floating point and 64-bit integer?
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0646}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 14:33:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg58887@s{hash}msg58887
@section 3 {tx}

  @p{««}Wiki page created: @p{(link}@s{(link)}(JSON-RPC@p{link)}) @p{»»}

  @p{««}genjix: You should be calling json.loads(...,
  parse_float=decimal.Decimal) and use a custom JSON encoder class to
  convert decimals to JSON strings with no loss of precision... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0647}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 15:26:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg58928@s{hash}msg58928
@section 3 {tx}

  @p{««}genjix: here is how to do it right in Python2.6 : @p{»»}

  @s{code}

  @p{««}Produces output: @p{»»}

  @s{code}

  @p{««} Note that EVEN IF YOU PASSED THE 'WRONG' strings to Bitcoin,
  Bitcoin would do the right thing. That is, these two are equivalent once
  they are parsed by bitcoin: @p{»»}

  @s{code}

  @p{««}... because bitcoin does proper rounding. @p{»»}

  @p{««}On the bitcoin side, this is a non-issue. And if code on the other
  end of the JSON-RPC connection does the wrong thing (truncates values
  like 10.000999999999999 instead of rounding them to the nearest 8'th
  decimal place) then that's a bug in that code. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0648}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 15:45:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4069.msg58951@s{hash}msg58951
@section 3 {tx}

  @p{««}You can't open and close the file; it is not thread-safe (thread
  one closes fp and sets it to NULL and sleeps, thread two wakes up and
  uses a NULL fp). @p{»»}

  @p{««}And you can't wrap the open/close in a CRITICAL_SECTION, because
  logging happens at shutdown, CRITICAL_SECTION relies on a destructor to
  work properly, and you can't control the order in which C++ destructors
  are called during shutdown. @p{»»}

  @p{««}I learned all that the hard way a few releases back. @p{»»}

  @p{««}You can rotate the logs using the "copytruncate" feature of
  @p{(link}logrotate@p{link)}.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0649}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 19:57:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4098.msg59131@s{hash}msg59131
@section 3 {tx}

  @p{««}Oops. @p{»»}

  @p{««}My fault@p{--} I DID test downloading the entire production block
  chain with a 0.3.20 client, but I wasn't careful to make sure I
  downloaded it from another 0.3.20 client. @p{»»}

  @p{««}Workaround: if you are running 0.3.20, run with
  -maxsendbuffer=10000 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0650}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 20:06:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg59137@s{hash}msg59137
@section 3 {tx}

  @s{quotedtext}

  @p{««}Huh? See that 'import json' statement at the top? That would be the
  standard (as of python 2.6) JSON parsing library. @p{»»}

  @p{««}The code I posted tells the standard JSON parsing library to read
  JSON Numbers as Decimal. If you are doing monetary calculations in
  python, then you should be using Decimal. That is what it is for. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0651}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 21:03:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4098.msg59196@s{hash}msg59196
@section 3 {tx}

  @s{quotedtext}

  @p{««} 500MB per connection times 100 connections would be 50 GB. That
  re-opens the door to a memory exhaustion denial-of-service attack, which
  is the problem -maxsendbuffer fixes. @p{»»}

  @p{««}As transaction volume grows I think there will be lots of things
  that need optimization/fixing. One simple fix would be to request fewer
  blocks as they get bigger, to stay inside the sendbuffer limit... @p{»»}

  @p{««}(ps: I've been re-downloading the current block chain connected to
  a -maxsendbuffer=10000 0.3.20 node, and the workaround works)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0652}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-03 21:30:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4098.msg59215@s{hash}msg59215
@section 3 {tx}

  @p{««}Please help test: @s{(link)} @p{»»}

  @p{««}Sets the -maxsendbuffer and -maxreceivebuffer limits to 10MB each
  (so possible max of 2GB of memory if you had 100 connections). @p{»»}

  @p{««}I tested by running a 0.3.20 node to act as server, then ran a
  client with: @p{»»}

    @p{(li}@s{code} ... to make sure
  I was downloading the block chain from that 0.3.20 node. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0653}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 01:29:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4097.msg59981@s{hash}msg59981
@section 3 {tx}

  @s{quotedtext}

  @p{««} There was a good @p{(link}Skeptoid podcast about it@p{link)}.
  @p{»»}

  @p{««}Our brains are really good at pattern-matching, and are really good
  at fooling us into seeing patters where none exist. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0654}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 01:32:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4123.msg59984@s{hash}msg59984
@section 3 {tx}

  @p{««}fread failed means bitcoin couldn't read some data off of your hard
  disk. @p{»»}

  @p{««}You might want to invest in a copy of @p{(link}SpinRite@p{link)}
  and check your hard disk for errors. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0655}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 14:52:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4140.msg60277@s{hash}msg60277
@section 3 {tx}

  @s{quotedtext}

  @p{««} I wouldn't have any objections to changes that let you decide
  which input transactions or receiving addresses to choose when sending
  coins, as long as it is well-tested, follows the coding guildelines (see
  coding.txt in the source directory) and it doesn't make the "I just want
  to send some coins" case look more complicated (maybe hide it behind an
  Advanced... button in the Send dialog). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0656}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 15:34:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4149.msg60293@s{hash}msg60293
@section 3 {tx}

  @p{««}Nice analysis! I'm tempted to put a link to your post in the code
  as a comment... @p{»»}

  @p{««}The whole transaction prioritization scheme was written by Satoshi
  after I suggested that de-prioritizing "small new" transactions might
  help the spamming problem. In the last couple of days we've exchanged
  email about possibly modifying it; @p{(link}pull request 88@p{link)} is
  the first suggested change (it makes the CreateTransaction fee
  calculations match the CreateBlock calculations). @p{»»}

  @p{««}Until somebody finishes implementing lightweight
  '@p{(link}headers-only block download@p{link)}', we should try to keep
  block size small@p{--} otherwise new users will have to wait an even
  longer time before being able to use bitcoin. @p{»»}

  @p{««}Also: the Faucet is now paying a 0.01 BTC fee per transaction. With
  the CreateTransaction fix, it probably would be anyway (the transactions
  it creates look very spammy). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0657}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 16:54:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4166.msg60351@s{hash}msg60351
@section 3 {tx}

  @p{««}I was editing the bitcoin.org homepage to update the download
  links, and I couldn't resist make a few changes: @p{»»}

  @p{««} @p{(li}I removed the "If you are running version 0.3.9 or earlier
  please update" message. People running really old versions of bitcoin
  SHOULD update, but there is no longer any security risk if they
  don't.@p{li)}

    @p{(li}I replaced "there were X blocks as of Y date" with a link to
    jgarzik's Bitcoin Watch site.@p{li)}

    @p{(li}I made the SHA1 checksums at the bottom of the page tooltips of
    the download links. I think it is easier to match up checksums to
    filenames that way, and I think it looks less intimidating for people
    who have no idea what SHA means.@p{li)}

  @p{««}PS: I read the thread about replacing the self-signed bitcoin.org
  security certificate, and agree that needs to be done... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0658}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 17:04:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4135.msg60355@s{hash}msg60355
@section 3 {tx}

  @p{««}fopen() is a standard C library call; it is weird Bitcoin can't
  find it. @p{»»}

  @p{««}Is anybody else running bitcoin on OSX 10.5 ? I'm running 10.6.6;
  Laszlo does the OSX builds, I'll ask him what he's running. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0659}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 17:23:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4167.msg60365@s{hash}msg60365
@section 3 {tx}

  @p{««}The @p{(link}maxsendbuffer bug@p{link)} (0.3.20.1 clients not being
  able to download the block chain from other 0.3.20.1 clients) was only
  going to get @p{brk} worse as people upgraded, so I cherry-picked the
  bug fix and created a minor release yesterday. @p{»»}

  @p{««}The @p{(link}Amazon Machine Images@p{link)} I used to do the builds
  are available: @p{»»}

  @s{code}

  @p{««}(mac build will be done soon) @p{»»}

  @p{««}If you have already downloaded version 0.3.20.1, please either add
  this to your bitcoin.conf file: @p{»»}

  @s{code}

  @p{««}... or download the new version.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0660}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 18:04:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4167.msg60381@s{hash}msg60381
@section 3 {tx}

  @s{quotedtext}

  @p{««} The tag is v0.3.20.2, and it is signed by my
  (@p{(link}gavinandresen@s{at}gmail.com@p{link)}) gpg key. @p{»»}

  @p{««}RE: roadmap for v0.4 : I worry that we'll spend time creating a
  roadmap and then... people will work on whatever strikes their fancy. So
  the 0.4 release will end up being completely different from what the
  roadmap says. @p{»»}

  @p{««}That said, I'll start a roadmap thread; maybe we CAN all agree on
  priorities and find people to actually work on the highest priority
  stuff. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0661}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 18:09:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4170.msg60385@s{hash}msg60385
@section 3 {tx}

  @p{««}Crashing bugs, any bug that might result in loss of bitcoins, and
  security fixes are always highest priority, but here are the big things
  I think are very high priority that, as far as I know, nobody is working
  on. I think they all need to be done before we can say we have a
  "Bitcoin 1.0" : @p{»»}

  @p{««} @p{(li}finish download-only-blockheaders client mode@p{li)}

    @p{(li}password-protect the wallet private keys (mitigate the steal
    wallet.dat problem: see @s{(link)} )@p{li)}

    @p{(li}import a backed-up wallet@p{li)}

    @p{(li}figure out how to do click-to-pay@p{li)}

    @p{(li}design/implement a secure DNS-like "map string to bitcoin
    address" system (so I can send bitcoins to
    "@p{(link}gavin@s{at}acm.org@p{link)}")@p{li)}

    @p{(li}export+encrypt part of your balance (for long-term storage; I
    still waffle on whether we want to encourage that right now)@p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0662}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 19:39:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4120.msg60438@s{hash}msg60438
@section 3 {tx}

  @s{quotedtext}

  @p{««}Clearcoin now supports sending unreleased coins to a charity
  instead of refunding them, which gives both buyer and seller the same
  incentives.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0663}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 21:57:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4180.msg60538@s{hash}msg60538
@section 3 {tx}

  @p{««}Good idea. I opened a feature request at @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0664}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 22:07:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4170.msg60544@s{hash}msg60544
@section 3 {tx}

  @s{quotedtext}

  @p{««} I suppose if we figure out how to make click-to-pay work for both
  the "I'm using an online wallet service" and the "I'm using the client"
  cases, then users won't have to know how to copy&amp;paste addresses and
  human-type-able addresses won't be critical. @p{»»}

  @p{««}RE: DoS resistance: please DO keep thinking about it; I'm not a
  networking expert (in fact, if you know any networking experts, see if
  you can get them thinking about it....). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0665}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 22:16:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2931.msg60549@s{hash}msg60549
@section 3 {tx}

  @p{««}Pull request: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0666}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-05 22:22:08 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4166.msg60553@s{hash}msg60553
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is amazing how the brain can ignore things that it sees every
  single day... (thanks for pointing that out, fixed). @p{»»}

  @p{««}RE: removing wording about generating coins on the home page: any
  objections to doing that?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0667}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 01:55:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4097.msg60665@s{hash}msg60665
@section 3 {tx}

  @s{quotedtext}

  @p{««} Conversation I had tonight: @p{»»}

  @s{quotedtext}

  @p{««} People who know me aren't shocked that I'm working on something
  wild and crazy, and by saying up front "this is a wild and crazy idea
  that may or may not work" I think they're more likely to really think
  about whether or not bitcoin makes sense. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0668}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 01:59:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4175.msg60666@s{hash}msg60666
@section 3 {tx}

  @s{quotedtext}

  @p{««} Maybe it is time to start a bitcoin @p{(link}stack exchange
  site@p{link)}? @p{»»}

  @p{««}Forums aren't really designed for Q&amp;A. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0669}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 02:13:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4182.msg60668@s{hash}msg60668
@section 3 {tx}

  @s{quotedtext}

  @p{««} You mean fairly large fluctuations in BTC/$ prices? Yes, yes it
  will. If you're looking for a stable, boring investment do not buy
  bitcoins. @p{»»}

  @p{««}I'm still surprised we haven't seen a real @p{(link}price
  bubble@p{link)} yet (where my definition of bubble is "doubles in price
  and then falls all the way back down"). Maybe we're in the middle of one
  still on its way up... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0670}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 02:30:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4170.msg60675@s{hash}msg60675
@section 3 {tx}

  @s{quotedtext}

  @p{««} Cool... but Hal just convinced me we don't need that feature for
  bitcoin 1.0. @p{»»}

  @p{««}Is anybody willing to commit to actually implementing any of these?
  @p{»»}

  @p{««}I know the bitcoin@p{lt}-@s{gt}Berkeley DB code pretty well, so
  I'll volunteer to do the "Import a backed up wallet" feature. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0671}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 02:52:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4166.msg60682@s{hash}msg60682
@section 3 {tx}

  @s{quotedtext}

  @p{««} WAAAAAY back in May of last year I did a little CPU mining. Then
  stopped when I realized I was spending more on electricity than the
  bitcoins I generated were worth. Bitcoins were selling for under a penny
  a piece, and I figured it cost a couple cents in electricity to mine
  them. @p{»»}

  @p{««}So if you think there's a chance bitcoin prices will be 10 or 100
  times higher in the next year or three, maybe CPU mining now isn't
  crazy. @p{»»}

  @p{««}Just saying.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0672}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-06 17:37:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4170.msg61050@s{hash}msg61050
@section 3 {tx}

  @s{quotedtext}

  @p{««} You're browsing the web and see a link or button that says "Pay
  now with Bitcoin"@p{--} you click it, and... stuff happens. Where that
  stuff does NOT involve copying and pasting anything (I know WE all know
  how to copy and paste, but a surprising number of computer users don't)
  and certainly doesn't involve trying to type in a 35-character bitcoin
  address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0673}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 15:59:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191.msg61586@s{hash}msg61586
@section 3 {tx}

  @s{quotedtext}

  @p{««} So lets say I can create SHA-256 collisions fairly easily, and I
  want to replace an old transaction somewhere in the block chain. @p{»»}

  @p{««}I create an alternate version of the transaction with the same
  hash... and then? Whenever clients happen to connect to my node to get
  old transactions I feed them the bogus version? @p{»»}

  @p{««}How do I get a majority of the network to accept the bogus version
  as valid, when the majority of the network probably already has already
  downloaded the old, valid version? @p{»»}

  @p{««}Same question if I'm creating duplicate (old) block hashes instead
  of duplicate transaction hashes. @p{»»}

  @p{««} I suppose I could try to double-spend with two transactions that
  hash to the same value... and hope that the merchant's bitcoin accepts
  Transaction Version 1 while the majority of the rest of the network
  accepts Transaction Version 2 (where I pay myself). But if SHA-256 ever
  gets close to being broken I'm sure bitcoin will be upgraded so new
  clients only accept upgraded hashes for new blocks/transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0674}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 16:15:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191.msg61601@s{hash}msg61601
@section 3 {tx}

  @p{««}RE: changing things now "just in case" : @p{»»}

  @p{««}No, I think it would be dumb to switch hashing algorithms or
  public/private keylengths now, for at least two reasons: @p{»»}

    @p{(li} 1. You'd just be switching from older technology that has the
    advantage of being well-tested and "battle-hardened" to something
    newer that you THINK will be more secure. @p{li)}

    @p{(li} 2. There are much more important things to work on. If you
    know enough about crypto to evaluate whether Whirpool really is
    fundamentally more secure than SHA-256, please apply your knowledge to
    the problems we have right now, like making users' wallets more secure
    against trojans and malware... @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0675}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 19:57:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4254.msg61749@s{hash}msg61749
@section 3 {tx}

  @p{««}Code: sendmany @p{lt}fromaccount@s{gt} {address:amount,...}
  (minconf=1) (comment) @p{brk} amounts are double-precision floating
  point numbers @p{»»}

  @p{««} @s{(link)} @p{»»}

  @p{««}Need for this is being driven by mining pool operators; it is much
  more efficient to pay lots of people with one transaction rather than
  lots of little transactions. @p{»»}

  @p{««}Old clients will refuse to relay sendmany transactions, so to
  ensure timely inclusion in a block mining pool operators should either
  upgrade together and connect their clients together or wait until a good
  percentage of the network has had a chance to upgrade to the next
  version of bitcoin. @p{»»}

  @p{««}Examples of use from a bash command-line (note you have to quote
  the second 'object' argument because the {} characters are interpreted
  by bash): @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms0676}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 20:18:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4239.msg61758@s{hash}msg61758
@section 3 {tx}

  @s{quotedtext}

  @p{««} There is no bug, but if you want to know one of your customer's
  bitcoin addresses (maybe you want to send them a refund?) you
  @p{(bf}must@p{bf)} ask them. They might be using an escrow service like
  ClearCoin or, as theymos says, using a shared wallet service like
  MyBitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0677}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 21:35:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4258.msg61804@s{hash}msg61804
@section 3 {tx}

  @p{««}I was just about to ask the same thing as LMGTFY.... @p{brk}
  Running anybody else's code on your system is dangerous. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0678}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-07 21:44:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4254.msg61812@s{hash}msg61812
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is not a new transaction type@p{--} transactions could always
  have multiple TxOuts. @p{»»}

  @p{««}However, to prevent a denial-of-service attack (which was actually
  attempted@p{--} see @p{(link}block 71036@p{link)}) transactions with
  more than 2 TxOuts are currently dropped by clients instead of relayed.
  @p{»»}

  @p{««}Now that there is a need for it, the rules allow "reasonable"
  multi-output transactions, but still denies "unreasonable" ones
  (reasonable means: is one of the 2 standard transaction types and only
  does one ECDSA signature verification per recipient). @p{»»}

  @p{««}So: no, this won't cause a block chain split. And no, old miners
  will not disagree with new miners, so double-spending is not possible.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0679}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-08 23:07:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4254.msg62626@s{hash}msg62626
@section 3 {tx}

  @s{quotedtext}

  @p{««}Sure, here's one: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0680}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-08 23:31:07 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4306.msg62642@s{hash}msg62642
@section 3 {tx}

  @p{««}The Bitcoin Faucet ran out of coins this morning, so I took that as
  a sign that I should make some changes that I've been meaning to make
  for a while. @p{»»}

  @p{««}The big change is the Faucet now requires you to have a Google
  account (and login with your Google Account) to get coins. With IPv6
  starting to happen, and people getting ever more creative in the ways
  they tried to get around the "X bitcoin per unique IP address" rule, I
  decided to let Google catch people trying to create lots of accounts.
  @p{»»}

  @p{««}From what I remember, the cost of buying a google account is much
  higher than the value of the coins I'm giving out (as opposed to the
  cost of hiring somebody to solve captchas), so the only people working
  hard to create new Google accounts to try to rip off the Faucet will
  likely be teenagers with way too much time on their hands. @p{»»}

  @p{««}One little change: Faucet pay-outs are now: @p{»»}

    @p{(li}0.11 BTC when balance @s{gt} 500 BTC @p{li)}

    @p{(li}0.05 otherwise (same as before). @p{li)}

  @p{««}And an invisible change that actually happened a few days ago: the
  Faucet pays a 0.01 transaction fee every time it sends coins. That makes
  Faucet transactions get into blocks quicker when there are lots of other
  free transactions on the network, and leaves more room in blocks for
  free transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0681}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 00:45:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4306.msg62672@s{hash}msg62672
@section 3 {tx}

  @p{««}Thanks@p{--} there was indeed a bug in the "weren't you just here?"
  code... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0682}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 00:58:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4220.msg62676@s{hash}msg62676
@section 3 {tx}

  @p{««}You can't send messages with transactions. @p{»»}

  @p{««}There was some discussion of adding another "standard" transaction
  type that allowed you to add N bytes of arbitrary data. I think that is
  a good idea (I think people would find all sorts of interesting uses for
  it), but there are higher priority things on the development roadmap.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0683}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 01:33:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4306.msg62696@s{hash}msg62696
@section 3 {tx}

  @p{««}Maintaining the faucet isn't a big drain on my time@p{--} most days
  I don't think about it. @p{»»}

  @p{««}Given the number of newbies who wander into @s{hash}bitcoin-dev and
  mention they got 0.05 BTC from the faucet, I think it is still valuable
  as a nice introduction to using bitcoin. @p{»»}

  @p{««}And Jim: thanks! Without donations the Faucet would have run out of
  coins long ago... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0684}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 02:20:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4277.msg62718@s{hash}msg62718
@section 3 {tx}

  @s{quotedtext}

  @p{««} Somebody did that a few months ago (theres a message here in the
  forums SOMEWHERE...) @p{»»}

  @p{««}If I recall correctly, after he was done he found that it wouldn't
  compile on Windows any more. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0685}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 19:18:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4324.msg63057@s{hash}msg63057
@section 3 {tx}

  @s{quotedtext}

  @p{««} You can run the front-end on one server and the back-end on
  another (and communicate via JSON-RPC over HTTPS). That's how I'm able
  to run the Faucet and ClearCoin on Google's App Engine (they talk with
  bitcoind processes running on linode.com and aws.amazon.com servers).
  bitcoind doesn't take much memory, bandwidth, or CPU (just don't turn on
  coin generation), so, for now, anyway, you can even use an Amazon
  "micro" server (which costs something like $100 per year). @p{»»}

  @p{««}I'm not selling anything so can't comment on the shopping cart
  interfaces. Screen-scraping web pages is a bad idea for lots of reasons.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0686}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 21:36:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4328.msg63138@s{hash}msg63138
@section 3 {tx}

  @p{««}Making the fee transaction depend on the block's coinbase would run
  afoul of this code in CTransaction::ConnectInputs: @p{»»}

  @s{code}

    @p{(li} if (txPrev.IsCoinBase()) @p{li)}

    @p{(li} for (CBlockIndex* pindex = pindexBlock; pindex &amp;&amp;
    pindexBlock-@s{gt}nHeight - pindex-@s{gt}nHeight @p{lt}
    COINBASE_MATURITY; pindex = pindex-@s{gt}pprev) @p{li)}

    @p{(li} if (pindex-@s{gt}nBlockPos == txindex.pos.nBlockPos &amp;&amp;
    pindex-@s{gt}nFile == txindex.pos.nFile) @p{li)}

    @p{(li} return error("ConnectInputs() : tried to spend coinbase at
    depth %d", pindexBlock-@s{gt}nHeight - pindex-@s{gt}nHeight); @p{li)}

  @p{««} ... and the entire block would be rejected as invalid. Which is a
  good thing, otherwise miners could get around the "no spending newly
  minted coins for COINBASE_MATURITY blocks" rule. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0687}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-09 22:03:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4335.msg63157@s{hash}msg63157
@section 3 {tx}

  @p{««}RE: 25 outbound connections instead of 8: @p{»»}

  @p{««}If I recall correctly (and I probably don't), the percentage of
  nodes currently on the network that are accepting incoming connections
  and the -maxconnections limit isn't great enough to support every node
  trying to make 25 outbound connections. @p{»»}

  @p{««}The major merchants and exchanges should accept incoming
  connections, so they have many more than 8 connections. That will make
  them basically immune to Sybil attacks (e.g. the Faucet has 55
  connections right now). @p{»»}

  @p{««}I like the idea of major merchants and exchanges (also)
  communicating with each other over an invitation-only, trusted
  "backbone." That would be in addition to the mostly-randomly-connected
  p2p network we have now, not instead of it. @p{»»}

  @p{««}I'm concerned about Sybil attacks as a denial-of-service technique
  (attacker "surrounds" an 8-connection node and then drops all of their
  transactions just because they can). Randomly disconnecting and
  re-connecting seems like a good approach. @p{»»}

  @p{««}Detecting that you're being subjected to a Sybil attack seems like
  it might also be a good approach. You don't really care if you're seeing
  a bogus version of the block chain unless you're in the middle of
  confirming one or more transactions; perhaps if transaction confirmation
  is taking significantly longer than expected the client should find some
  fresh peers. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0688}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-10 06:56:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4335.msg63425@s{hash}msg63425
@section 3 {tx}

  @s{quotedtext}

  @p{««} Well, imagine an attacker did manage to surround your node.
  @p{brk} What can they do? @p{»»}

  @p{««}a) Dropping outgoing transactions@p{--} a send-coins
  denial-of-service. @p{li)}

  b) Dropping incoming transactions@p{--} a 0-confirmation-receive-coins
  denial-of-service @p{»»}

  @p{««}Can these be exploited somehow to the attacker's advantage? Maybe
  if attacker and attackee were competing on a bidding site or the site
  being attacked was a bidding site and the attacker wanted to squash
  competing bids. Rounding up thousands of IPs to try to get a better deal
  on biddingpond hardly seems worth it. And an old-fashioned DDoS attack
  can probably take out any one particular node anyway, with or without
  bitcoin involved. @p{»»}

  @p{««}c) Dropping new block announcements (that would be a
  1+-confirmation-receive-coins DoS) @p{li)}

  d) ... and maybe feeding the attacked node attacker-generated blocks
  @p{»»}

  @p{««}(d) is more serious, because the attacker could generate bogus
  N-confirmation transactions. But it should be detectable; assuming the
  attacker doesn't have as much hashing power as the rest of the network,
  blocks will be generated much more slowly (either much more slowly after
  the last compiled-in block checkpoint if you're downloading the block
  chain, or much more slowly since the last time your node connected to
  the network). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0689}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-10 19:00:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4328.msg63624@s{hash}msg63624
@section 3 {tx}

  @p{««}I think you have an incorrect assumption in your argument: what
  makes you think there will be a high variability in block rewards
  (because they're mostly fees) 40 years from now? @p{»»}

  @p{««}Assuming bitcoin is still around in 40 years, there should be at
  least tens of thousands of transactions per block, and with that many
  transactions sum(fees) should be pretty darn stable. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0690}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-11 17:31:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4306.msg64011@s{hash}msg64011
@section 3 {tx}

  @s{quotedtext}

  @p{««} The Donate: address is hiding down at the bottom of the page:
  @s{btcaddress} @p{brk} ... and I just updated my forum signature,
  too.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0691}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-11 21:17:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg64135@s{hash}msg64135
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why can't you just multiply the numbers by 1.0e8 and then round to
  the nearest integer? That integer WILL ALWAYS BE EXACTLY RIGHT (assuming
  you're not running PHP on some really weird hardware). @p{»»}

  @p{««}According to the PHP manual: @p{»»}

  @s{quotedtext}

  @p{««} I added a Python JSON-RPC library example on the @p{(link}Proper
  Money Handling@p{link)} wiki page. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0692}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 01:31:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4353.msg64242@s{hash}msg64242
@section 3 {tx}

  @s{quotedtext}

  @p{««} In my head I was imagining a way of telling bitcoin to subscribe
  to some service(s) that did the mapping@p{--} maybe a setting in the GUI
  where you could specify "use these six services, in this order, to try
  to resolve bitcoin addresses that aren't plain-old-bitcoin-addresses."
  With the services specified by name+URL (and some standard REST-ful
  protocol was defined for mapping string to bitcoin address). Or maybe
  name+pattern+URL. @p{»»}

  @p{««}I haven't looked at genjix' patch, and haven't thought deeply about
  security issues@p{--} but I bet there are lots... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0693}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 03:18:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4353.msg64291@s{hash}msg64291
@section 3 {tx}

  @p{««}Seems like this feature doesn't need to be part of the RPC
  interface@p{--} why not just (ignoring error handling/etc) do the
  equivalent of: @p{»»}

   @s{code}

  @p{««} ... from whatever code is calling the RPC? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0694}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 03:21:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4392.msg64292@s{hash}msg64292
@section 3 {tx}

  @s{quotedtext}

  @p{««} Who knows enough about wxWidgets to add a checkbox to the Settings
  UI for "Enable UpNP" (grayed out @s{hash}ifndef UPNP...)? Wanna coordinate with
  BlueMatt to get that done? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0695}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 15:24:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg64496@s{hash}msg64496
@section 3 {tx}

  @p{««}Is there a PHP implementation that does not use double-precision
  floating point? @p{brk} After doing a little googling I couldn't figure
  out the answer to that. I will be MUCH more sympathetic to changing the
  JSON-RPC api if there is. @p{»»}

  @p{««}And mizerydearia: re: the witcoin issue: You say: @p{brk} "I see
  the transaction as 0.94 However, @s{(link)} retrieves the data as
  0.93999999999999994671" @p{»»}

  @p{««}So why when you display that value are you truncating it instead of
  rounding it to 8 decimal places? @p{brk} For example: @p{»»}

  @s{quotedtext}

  @p{««} ... or to convert to an integer-number-of-base-unit: @p{»»}

  @s{quotedtext}

  @p{««} All of that assume that your php support double-precision floating
  point, which brings me back to my question: are there any php
  implementations that do not?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0696}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 16:12:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg64517@s{hash}msg64517
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's just dumb. @p{»»}

  @p{««}If the problem is jsonrpc-supporting-environments that don't
  support double-precision floats, then multiplying and slapping a zero on
  the end won't fix the problem@p{--} you'll just either lose precision as
  it gets squeezed into a 32-bit float or get a 32-bit-integer-overflow
  error. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0697}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 17:35:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg64549@s{hash}msg64549
@section 3 {tx}

  @s{quotedtext}

  @p{««} You know, I was looking at the PayPal payment API yesterday, and
  $1.01 is sent as... 1.01 @p{»»}

  @p{««}"transmitting" != "calculations" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0698}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 20:27:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4411.msg64632@s{hash}msg64632
@section 3 {tx}

  @s{quotedtext}

  @p{««} Something like this is possible (I've been thinking about doing
  it, although I have higher priority things on my TODO list): @p{»»}

  @p{««} @p{(li}Sophisticated user runs a tool on her computer that, giving
  the bitcoin address payment was sent to and "here's a description of me
  or what I paid for" string. Tool looks in the wallet.dat and figure out
  which keypair(s) were used to pay. Then it does some openssl magic and
  exports a file that contains the string, the public keys and ECDSA
  signatures using the private keys of the "description of me or what I
  paid for" string.@p{li)}

    @p{(li}Sophisticated user uploads that file to a "Prove I Paid"
    website, which checks the signatures and adds info to the
    database.@p{li)}

    @p{(li}Unsophisticated user goes to website and pastes the receiving
    address. The public key corresponding to that address is looked up,
    and all the "here's a description of me or what I paid for" strings
    for that public key are shown.@p{li)}

  @p{««}bitcointools+openssl (see grondilu's thread about "a shell-script
  implementation of bitcoin) are enough to do all all the public/private
  key, file-creation, and signature generation/checking stuff. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0699}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-12 23:58:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4223.msg64714@s{hash}msg64714
@section 3 {tx}

  @p{««}Who's that woman: @p{»»}

    @p{(li}@p{(link}Anna Lee@p{link)} @p{li)}

  @p{««}I don't know nuthin 'bout changing video default images. @p{»»}

  @p{««}If anybody does, I'd be happy to replace or tweak the link to the
  video at bitcoin.org. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0700}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-13 00:19:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4140.msg64717@s{hash}msg64717
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sticky for creating a pull request: good idea. @p{»»}

  @p{««}JollyGreen: if you know, or are willing to learn, git then working
  from the git repo ( @s{(link)} )is smoother. github has built-in support
  for turning a development branch into a pull request. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0701}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 11:55:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg65210@s{hash}msg65210
@section 3 {tx}

  @s{quotedtext}

  @p{««} I tried it... got -999.04 on my Mac and Linux machines. What
  platform gives the wrong answer? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0702}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 17:13:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg65317@s{hash}msg65317
@section 3 {tx}

  @p{««}PHP 5.3.3. on my mac gives: @p{»»}

  @s{code}

  @p{««} Please be specific about what platform you're running on, what
  version of PHP are you running, are you running with a standard php.ini
  or have you tweaked it, etc.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0703}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 17:21:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4448.msg65323@s{hash}msg65323
@section 3 {tx}

  @p{««}I'd suggest using a standard, existing format instead of inventing
  a new one. @p{»»}

  @p{««}Either get rid of the version number and do standard CSV: @p{»»}

  @p{««}Code:
  91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY,10806,moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD,"50.01
  BTC" @p{brk}
  92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L,10870,mmFPR1oaDExBfJqpRohWBvbE2aCg86Kwcx,"0.00
  BTC" @p{brk} ... etc (always 4 columns) @p{»»}

  @p{««} Or maybe .ini-format, with each private key a different section:
  @p{»»}

  @s{code}

    @p{(li}... etc @p{li)}

  @p{««}(bitcoin already contains .ini-file-parsing code, from boost) @p{»»}

  @p{««} I think there are lots of advantages to using an already-standard
  file format. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0704}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 20:33:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4392.msg65395@s{hash}msg65395
@section 3 {tx}

  @s{quotedtext}

  @p{««} Preventing that type of statistical network analysis attack is
  what Tor and i2p are for. If you require that level of anonymity, run
  bitcoin via a proxy to communicate over those networks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0705}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 20:43:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4448.msg65398@s{hash}msg65398
@section 3 {tx}

  @p{««}Focusing on the use cases is the right approach. @p{»»}

  @s{quotedtext}

  @p{««} One variation: @p{»»}

    @p{(li} 5. Export keys to transfer funds to somebody else. Recipient
    is expected to import and then immediately send-to-self. Sender keeps
    the keys 'set aside' in the wallet until they are spent by recipient,
    or, if not spent by recipient (lost in transit maybe, or recipient
    chokes on a lollipop before having a chance to redeem), may be added
    back into the sender's balance. @p{li)}

  @p{««}And one usability comment: @p{»»}

  @p{««}Is "selected keys" the right way to go? Just selecting an amount of
  bitcoins to export/send seems like a better way to go (with a
  send-to-self transaction generated, if necessary, to create the right
  amount), with maybe an "advanced" option later that lets you select
  specific inputs to export/send. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0706}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 21:08:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg65407@s{hash}msg65407
@section 3 {tx}

  @p{««}So I got email today from a merchant asking the
  most-frequently-asked question: if I just put a bitcoin address on my
  "pay me" page, how do I know who paid me? @p{»»}

  @p{««}Which got me to wondering... can we do better than answer "run a
  bitcoin daemon and ask it for a new address for every order" or "use a
  shopping cart interface from your online wallet provider" ? @p{»»}

  @p{««}Ideally, the web software could generate a payment URI without
  talking to bitcoind, and copying/pasting or clicking on the URI would
  generate a transaction tagged with the right order ID. @p{»»}

  @p{««}Adding another transaction type that allows (say) an extra,
  arbitrary 512 bytes of data mostly solves the problem; the web software
  could encrypt or hash the order ID and generate a transaction that is
  the store's public bitcoin address and the encrypted/hashed order ID (or
  customer number or whatever). @p{»»}

  @p{««}Can we do better? It would be nice if it was impossible to tell how
  many orders the merchant was getting... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0707}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 21:24:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg65416@s{hash}msg65416
@section 3 {tx}

  @s{quotedtext}

  @p{««} The web server doesn't have the bitcoin private key, and the
  problem I'm trying to solve is an order process where the web server
  doesn't have to communicate with bitcoin at all to generate the "pay me"
  address/link. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0708}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-14 22:19:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg65472@s{hash}msg65472
@section 3 {tx}

  @p{««}RE: opening up the "store random stuff in the block chain"
  argument: @p{»»}

  @p{««}Several things make me not worried about that: @p{»»}

    @p{(li} 1. OP_CHECKSIG drives network-wide costs (see the thread on
    network-wide transaction cost back-of-the-envelope calculations).
    @p{li)}

  2. New -limitefreerelay code will, I'm pretty confident, mitigate
  penny-flooding. @p{li)}

  3. 512 bytes plus inputs plus outputs will will make these either
  "very-low-priority-free" or over 1K non-free transactions. @p{li)}

  4. We're past the point where block chain download size is 'convenient'
  for new users. We should implement lightweight client mode (download
  only block headers until you start solo mining) as soon as possible.
  @p{li)}

  @p{««} RE: pregenerate a bunch of addresses to use for payment: @p{»»}

  @p{««}I like that idea! If you're getting, say, 20 bitcoin orders a day
  then 1,000 addresses would last you a month. And even if you recycled
  them when you ran out it should be easy to match orders to addresses
  based on the transaction date and amount... @p{»»}

  @p{««} The whole "click to pay" feature needs to be figured out, and
  should work nicely in all four cases of (customer,merchant) using
  (bitcoin,online wallet). My brain isn't up to it today, though... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0709}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-15 11:44:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg65727@s{hash}msg65727
@section 3 {tx}

  @s{quotedtext}

  @p{««} Right, that was the problem I was hoping to brainstorm about. I
  didn't want to re-open the "add data to the transaction database"
  discussion (I think "add data to the block chain" is misleading, since
  transaction data isn't actually part of the block-header-chain or
  transaction-merkle-tree). @p{»»}

  @p{««}I'm still wondering if there is a way to create transactions on the
  web server, without talking to bitcoind, using a small-ish number of
  pregenerated public keys, such that each transaction is unique and
  competitors can't tell how many transactions belong to any particular
  merchant. @p{»»}

  @p{««}Pre-generating a bunch of keys works, assuming that competitors
  don't know the pre-generated keys (bad assumption long-term if they keys
  are re-used, since they could just order a bunch of stuff and note the
  keys used for paying).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0710}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-16 15:18:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4521.msg66274@s{hash}msg66274
@section 3 {tx}

  @p{««}It depends on how much you pay for electricity, what kind of
  computer you own (and what kind of graphics card it has), and whether or
  not you can figure out how to install and run "GPU mining" software.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0711}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 00:46:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4220.msg66552@s{hash}msg66552
@section 3 {tx}

  @s{quotedtext}

  @p{««} Googling for 'ECDSA broadband subliminal channel' to figure out
  what the heck you're talking about... @p{»»}

  @p{««}... doesn't that require that the recipient (as well as the sender)
  know the private key? @p{brk} (you encode the message in the 'k' param,
  which the recipient can only recover using the private key?)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0712}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 00:53:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4220.msg66554@s{hash}msg66554
@section 3 {tx}

  @p{««}Thanks for the link to the wikipedia page in the other thread... so
  receiver CAN recover 'k' given the public key and signature. @p{»»}

  @p{««}Cool! @p{»»}

  @p{««}That doesn't solve the problem I'd like to solve (because you still
  need to generate a new keypair for every transaction), but it is
  cool.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0713}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 01:13:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg66563@s{hash}msg66563
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yeah... I can imagine clever ways of obfuscating it such that you
  can't tell who's getting paid until they actually sign the transaction
  and spend the output. Make the txout something like: @p{»»}

  @s{code}

  @p{««}... and to spend the txin is: @p{lt}scriptsig@s{gt}
  @p{lt}public_key@s{gt} @p{lt}r1@s{gt} (where r1 is a random number used
  to obfuscate the publicly visible hash160). Or something like that (I
  shouldn't be thinking about cryptography when I'm this tired). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0714}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 01:31:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4534.msg66573@s{hash}msg66573
@section 3 {tx}

  @p{««}Very nice! @p{»»}

  @p{««}The 'sig opcount @p{lt}= 2' rule for tx relaying is slated to
  change with the 'sendmany' patch I pulled on Monday. @p{»»}

  @p{««}The new rule will be 'sig opcount @p{lt}= size/34 @p{»»}

  @p{««} @s{code}

    @p{(li} // attacks disallow transactions with more than one SigOp per
    34 bytes. @p{li)}

    @p{(li} // 34 bytes because a TxOut is: @s{code} @p{li)}

    @p{(li} // 20-byte address + 8 byte bitcoin amount + 5 bytes of ops +
    1 byte script length @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0715}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 12:01:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg66810@s{hash}msg66810
@section 3 {tx}

  @p{««}Actually, falling asleep last night I realized what I proposed
  would be yet another variation on an 'anybody can claim' transaction
  (anybody can just choose an r1 that make r1 XOR hash_xor_r1 evaluate to
  a hash that they own). @p{»»}

  @p{««}I think this would work: @p{»»}

  @s{code}

  @p{««}... supply @p{lt}scriptsig@s{gt} @p{lt}public_key@s{gt}
  @p{lt}r1@s{gt} to claim. @p{»»}

  @p{««}I'm not suggesting anything like this get implemented any time
  soon, I started this thread just to explore what is possible.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0716}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 14:46:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4566.msg66881@s{hash}msg66881
@section 3 {tx}

  @p{««}I got this question from an editor at TechWorld.com.au : @p{»»}

  @s{quotedtext}

  @p{««} ... and I'm looking for good answers.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0717}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 16:51:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4223.msg66928@s{hash}msg66928
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sirius and I both have access to the webserver, although Sirius
  knows a lot more about Drupal than I do. @p{»»}

  @p{««}But if somebody puts together Drupal templates (theme? what does
  Drupal call them/it?) with the spiffy new look I'd be happy to upload
  them. Or, even better, create a Drupal account for that somebody so they
  can update the look and content themself and fix the bugs that are
  almost certainly going to happen. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0718}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 17:29:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4571.msg66945@s{hash}msg66945
@section 3 {tx}

  @p{««}The bitcoin integration/testing source tree is at
  @p{(link}GitHub@p{link)}, and we (jgarzik/tcatm/gavinandresen right now)
  use GitHub's "pull request" feature to keep track of patches that people
  think are ready for integration into mainline bitcoin. This post is a
  walk-through of how to create a pull request. @p{»»}

    @p{(li} 1. You'll need a GitHub account; @p{(link}sign up for
    free@p{link)}, and @p{(link}set up git and ssh@p{link)} to work with
    GitHub. @p{li)}

    @p{(li} 2. You need a fork of the main bitcoin source tree. Login to
    your GitHub account, browse to the @p{(link}bitcoin project@p{link)},
    then poke the little 'Fork' button near the top of the screen. @p{li)}

    @p{(li} 3. Connect that fork at GitHub with source code on your
    development machine. The easiest way to do that is to clone your
    github fork, using the SSH Read+Write URL github shows you on your
    fork's page. @p{li)}
    
  @p{««}For example:@p{»»}

  @p{««}@s{code} Create
  a feature branch @p{brk} ... edit, test, re-edit, re-test... @p{brk} 
  @s{code} You might already have a clone of the
  bitcoin git tree that you've modified; you should push those changes
  into your new GitHub fork. Assuming you made your changes in the
  'master' branch on your machine (next time you should create a specific
  feature branch), the command would be: @p{»»}

  @p{««}@s{code} optional: lets you tidy up commits to create a clean patch @p{brk} 
  @s{code}
  @p{brk} 
  
  @p{(li} 4. Submit a PULL request by going to your fork's GitHub page,
  selecting the branch containing the changes you want pulled
  ("niftynewfeature" in the above example), and then poking the "Pull
  Request" button. Enter a good description of what your changes do and
  why they're a good idea and how everybody and their brother is already
  using them to make the world a better place .  @p{li)}

  @p{««}Eventually, if all goes well, after discussion and argument and
  nit-picking and revision, your changes will get pulled into the bitcoin
  repository. If all doesn't go well, you (or the core developers) can
  close your pull request and resubmit it when the feature is perfect.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0719}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 19:56:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4559.msg66994@s{hash}msg66994
@section 3 {tx}

  @s{quotedtext}

  @p{««} They can only invalidate transactions that they made (or further
  transactions that spend transactions that they made). That makes the
  attack a lot less likely in practice; if they had a lot of bitcoins, and
  purchased a lot of good or services (or exchanged them for dollars or
  euros) with a lot of people, then some of those people are likely to
  know WHO "they" are. And if they're in the same legal jurisdiction, it
  seems to me you'd have a pretty good case for suing them for fraud.
  @p{»»}

  @p{««}Even if 'they' decided to do this just to try to mess up the
  bitcoin network it might be messy for the exchanges to clean up but I
  don't think it would cripple them. The bitcoin client already trys to
  select "old money" when it creates transactions, so assuming that the
  exchange has a good cushion of bitcoins on deposit all the attacker is
  likely to accomplish is to invalidate their own deposits at the
  exchange. @p{»»}

  @p{««}All that said: I'm not going to advise people to hold money they
  can't afford to lose in bitcoins until the network has a lot more
  hashing power. There is still some risk while bitcoin is young. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0720}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 20:11:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg67003@s{hash}msg67003
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... I think that's right, you don't need the OP_OVER OP_ADD. You
  have to know the random number to generate a valid signature, given only
  its hash. @p{»»}

  @p{««}You'd have to be very careful NEVER to use the same random number
  anybody else has ever used or will ever use; if your 'random' number is
  an order number (or even common-hash-of-an-order-number) then you're
  sunk, anybody can generate a valid @p{lt}signature@s{gt}
  @p{lt}public_key@s{gt} @p{lt}r@s{gt} triple. @p{»»}

  @p{««}For two extra bytes per transaction it might be better to hash in
  the public key, just so people don't shoot themselves in the foot. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0721}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-17 22:10:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4580.msg67077@s{hash}msg67077
@section 3 {tx}

  @p{««}Actually, I'm surprised Mark doesn't remember (or maybe he just
  didn't want to get bogged down in details)@p{--} he paid for my lunch,
  and I paid him back in Bitcoins. @p{»»}

  @p{««}Which turned out to be a good deal for him, they went from about
  40cents apiece to something like 60cents apiece in the week or so it
  took him to setup a bitcoin account and give me his receiving address (I
  paid at the 'when we had lunch' exchange rate, of course). @p{»»}

  @p{««}If you have a bitcoin business and are thinking about advertising,
  FTL listeners might be a receptive market@p{--} and I bet you might be
  able to convince Mark and Ian to take payment in bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0722}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-18 00:42:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4575.msg67132@s{hash}msg67132
@section 3 {tx}

  @p{««}How long is the split? There's really no problem if the split is
  less than the block generation maturation time (20+ hours)@p{--} a bunch
  of miners will be disappointed on one side of the split or the other,
  but that's about the extent of the damage. @p{»»}

  @p{««}Longer than 24 hours... is kind of hard to imagine for a big
  country. @p{»»}

  @p{««}Would transactions continue to be processed: yes, but... the sudden
  drop in network hashing rate (and the drastic slow-down in block
  generation) might trigger future safety checks in Bitcoin, so you might
  have to do something special to tell it "yes, I really do want to
  generate transactions even though something weird is happening with the
  network." @p{»»}

  @p{««}If a little country or region got split from the main network, it
  will probably have a lot less hashing power and it will take much longer
  to generate the 100 blocks needed to start to cause problems. That's a
  feature, not a bug. @p{»»}

  @p{««}After communication was restored the more-difficulty block chain
  would "win" and transactions from the losing block chain would get
  retransmitted and move over to the more-difficulty chain. @p{»»}

  @p{««}If somebody had a super-secret communication channel that worked
  during the split they could use it to double-spend. But if the bad guys
  have a super-secret channel then probably some good guys would, too, and
  as jgarzik points out, it only takes one little link to relay blocks and
  prevent a split. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0723}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-18 13:55:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4546.msg67383@s{hash}msg67383
@section 3 {tx}

  @s{quotedtext}

  @p{««} You might care if you got the dollar bill from somebody you
  suspect is working for the Secret Police, you think think the Secret
  Police might be trying to trace payments by recording bill serial
  numbers, and you're spending the dollar to pay a local print shop to
  produce some illegal Subversive Propaganda. @p{»»}

  @p{««}That's roughly similar to tracing bitcoin transactions.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0724}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-19 13:50:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4459.msg67926@s{hash}msg67926
@section 3 {tx}

  @s{quotedtext}

  @p{««} Satoshi has a bunch of features that he 'figured out from the
  start' that are not implemented yet; I'll ask him if this is one of them
  after I figure out exactly what feature I want and convince myself it is
  possible to do securely. So I'm going to try to gather my thoughts and
  see if there is much point: @p{»»}

  @p{««}This is the main problem I was trying to solve: @p{»»}

  @p{««} @p{(li}A merchant's website should give the customer a unique
  payment address during the chekcout process. Ideally, generating that
  unique address would be done entirely on the web server without
  requiring a RPC call to a bitcoind process running somewhere.@p{li)}

  @p{««}Communicating with bitcoin or some merchant-services website during
  the checkout process adds another possible point of payment
  failure@p{--} it is better for the merchant if their customers can
  continue to pay them even if their bitcoin daemon (or MyBitcoin or MtGox
  merchant services) is temporarily down for maintenance. @p{»»}

  @p{««}OP_OVER OP_ADD solves that problem, and, thinking about it, has
  some other very nice properties. Here's how it would work in practice:
  @p{»»}

    @p{(li} 1. Merchant gets one or more public keys to use for payments.
    They're stored in the web server's database. @p{li)}

    @p{(li} 2. Customer checks out: web server computes
    HASH160(public_key+order_id), and converts the result to a
    @p{(it}bitcoin address version@s{hash}2@p{it)} (first byte is not
    base58-encoded-0, but something else). @p{li)}

    @p{(li} 3. That bitcoin address makes its way to bitcoin software
    running on the customer's machine (or at an online wallet service).
    Since it is a version@s{hash}2 address, bitcoin creates an OP_OVER OP_ADD....
    transaction for it instead of an OP_DUP ... transaction. @p{li)}

    @p{(li} 4. Merchant's web server software tells a bitcoind running
    somewhere "if you see payments to HASH160(public_key+order_id), that's
    one of mine." @p{li)}

    @p{(li} 5. When the merchant want's to @p{(it}spend@p{it)} the
    bitcoins it got from the customer, it has to tell a bitcoind running
    somewhere the public_key,order_id pair. @p{li)}

  @p{««} If the merchant doesn't completely trust the payment processor
  then keeping steps (4) and (5) separate is very nice@p{--} the payment
  processor can't spend the merchant's bitcoins until the merchant tells
  them the order_ids (merchant would have to use truly random order_ids to
  be completely safe, of course). @p{»»}

  @p{««}And, as noted before, this is a little more private than standard
  bitcoin transactions because the public key isn't revealed until the
  coins are spent. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0725}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-19 17:56:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4223.msg68071@s{hash}msg68071
@section 3 {tx}

  @p{««}I don't want to hijack the design discussion... @p{»»}

  @p{««}... but I would like to open up discussion of content. I'd like to
  see the bitcoin.org home page to be less about bitcoin-the-software and
  more about bitcoin-the-currency. @p{»»}

  @p{««}You don't have to download and run any software to run bitcoin, and
  I think most non-technies are better off using an online wallet service
  rather than running bitcoin.exe. So I'd like to see the DOWNLOAD/HOWTO
  sections moved to a separate page, and have the home page have links to
  there and to a Wiki page that lists the online wallet services (and
  starts with a little discussion of the tradeoffs of using an online
  wallet provider instead of running bitcoin yourself). @p{»»}

  @p{««}I'd be perfectly happy if the design and content was improved (as
  already discussed) and then the content was changed later, if there's
  general agreement that de-emphasizing the download is a good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0726}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-19 19:13:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3612.msg68118@s{hash}msg68118
@section 3 {tx}

  @s{quotedtext}

  @p{««} I didn't@p{--} the first "community build" took long enough as it
  was, and I didn't want to add one more 'different from the way it was
  done before' variable. @p{»»}

  @p{««}Next release I want to automate some of the manual steps, and maybe
  use the gitian process, assuming it will work inside an Amazon VM (DO
  nested virtual machines work?). Unless anybody feels motivated to step
  in and do it first; with a verifiable build, anybody can take on the
  role of build-meister. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0727}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-19 19:18:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4666.msg68121@s{hash}msg68121
@section 3 {tx}

  @s{quotedtext}

  @p{««} The average user will want to use a brand name they're familiar
  with; if we can continue to convince early adopters that bitcoin is a
  good idea, eventually PayPal or one of its competitors will start
  supporting it. I hope. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0728}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-20 19:19:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4555.msg68620@s{hash}msg68620
@section 3 {tx}

  @s{quotedtext}

  @p{««}In jgarzik's original implementation, an attacker can pre-generate
  a rainbow table with 2^32 entries, and that lets them take a shortcut so
  they only have to try 2^32 bits for any particular scratch card
  (algorithm is, essentially, "foreach value in 2^32: do some complicated
  math, then see if the result matches a value in the 2^32-size rainbow
  table; if it does, you've found the unknown 2^64 bits"). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0729}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-20 20:12:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4680.msg68642@s{hash}msg68642
@section 3 {tx}

  @p{««}Thanks for the positive feedback! @p{»»}

  @p{««}Markus did a great job putting together an outline for what we'd
  talk about ahead of time, so I had time to plan how to explain
  complicated concepts like public key cryptography in just a couple of
  minutes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0730}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-20 20:35:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4692.msg68649@s{hash}msg68649
@section 3 {tx}

  @p{««}If more bitcoin adoption means bitcoin mining replaces actual,
  physical gold and silver mining then that should be a net positive for
  the environment. Gold mining is dirty, dangerous, and destructive; if
  bitcoins eventually become "a better gold", then there will be less
  pressure to dig up virgin wilderness. @p{»»}

  @p{««}Right now, bitcoin mining is inefficient, but natural economic
  forces will make it become increasingly efficient. We've already seen
  that, with more efficient GPU mining replacing CPU mining because you
  get more hashing for less electricity. @p{»»}

  @p{««}Eventually, I'm confident you'll see big commercial-scale bitcoin
  mining operations in places where either electricity is clean and cheap
  to produce, or where the waste heat from bitcoin production is put to
  productive use (maybe we'll all have network-connected bitcoin-mining
  space heaters to warm our offices in 10 years). @p{»»}

  @p{««}Before then, we probably @p{(bf}will@p{bf)} see bitcoin production
  using cheap, dirty electricity in poorer countries. If history is any
  guide, as that helps to make those countries richer their citizens will
  demand better environmental standards. Even if we all decided that is
  unacceptable, I don't see any way to prevent it@p{--} there's no way to
  tell if a bitcoin was generated using solar panels in the Sahara or
  dirty coal in Pennsylvania. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0731}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-21 01:19:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4721.msg68794@s{hash}msg68794
@section 3 {tx}

  @p{««}Neat idea! @p{»»}

  @p{««}As theymos says, this will only work 100% reliably for addresses
  buried "deep enough" in the block chain that the likelihood of a
  block-chain-re-org is vanishingly small. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0732}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-21 12:17:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4723.msg69022@s{hash}msg69022
@section 3 {tx}

  @s{quotedtext}

  @p{««}Making IsStandard() return true if fTestNet is a good idea. @p{»»}

  @p{««}The process for getting a new transaction type into bitcoin would
  be to test it thoroughly on the testnet, get general consensus on its
  API and/or GUI and that it is useful, safe, and unlikely to be abused,
  and work with the 'infrastucture' sites (like blockexplorer and
  bitcoinmonitor) to make sure the right APIs or hooks are in place so
  they can do something intelligent with the new transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0733}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-21 12:37:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4724.msg69032@s{hash}msg69032
@section 3 {tx}

  @p{««}I think there is a strong possibility bitcoins will end up being
  used for something none of us is thinking about. Maybe big multinational
  corporations will use them to pay their international supply chains in
  industries that are used to constant deflation. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0734}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-21 14:04:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4736.msg69068@s{hash}msg69068
@section 3 {tx}

  @p{««}The @p{(link}Open Bank Project@p{link)} aims: @p{»»}

  @s{quotedtext}

  @p{««} I was contacted by Ismail CHAIB, who wonders if bitcoiners "might
  be able and interested to contribute to the project." If defining an API
  to help bring more transparency to government, nonprofit, and perhaps
  corporate finances sounds interesting to you (I'd personally like to see
  much more government financial transparency): @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms0735}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-21 15:05:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4729.msg69105@s{hash}msg69105
@section 3 {tx}

  @s{quotedtext}

  @p{««} But how do you know that the transaction the hardware device
  signed is actually the transaction you wanted to make? You might THINK
  you're sending 100BTC to your brother, your computer will SAY you're
  sending 100BTC to your brother, but the trojan might change the
  destination address that goes in to the hardware device. @p{»»}

  @p{««}Unless the hardware device has some sort of display and physical
  button to OK the transaction. In which case the hardware device sounds a
  lot like a smart phone.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0736}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-23 02:28:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=697.msg70176@s{hash}msg70176
@section 3 {tx}

  @p{««}Wow! Great job, excellent video (I like fast), fully deserving of
  the bounty in my opinion. @p{»»}

  @p{««}And yeah, if it is OK with justmoon I think replacing my Ignite
  talk on the bitcoin.org homepage with the new video is a great idea.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0737}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-23 02:45:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4782.msg70194@s{hash}msg70194
@section 3 {tx}

  @p{««}RE: fractional reserve bitcoin banks: @p{»»}

  @p{««}I think it will happen, too. Because of the nature of bitcoins they
  could arrange so that their reserves can be audited by anybody (easiest
  way: prove they own a particular bitcoin address by signing something
  with its private key, then send all their reserves to that address).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0738}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-23 21:14:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4847.msg70860@s{hash}msg70860
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. The end of the chain can, and does, fork, but the forks are
  short and the network pretty quickly decides on the One True Chain.
  @p{»»}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

  @s{quotedtext}

  @p{««}Short answer: no. @p{»»}

  @p{««}Longer answer: it is complicated, and what you need depends on
  whether or not you're trying to generate new blocks. To keep it simple,
  the original client downloads everything. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0739}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-25 12:35:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4904.msg72018@s{hash}msg72018
@section 3 {tx}

  @s{quotedtext}

  @p{««}D'oh! @p{»»}

  @p{««}sendfrom should definitely CRITICAL_BLOCK(cs_main). Nice catch
  ArtForz. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0740}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-25 13:01:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4904.msg72030@s{hash}msg72030
@section 3 {tx}

  @p{««}Does anybody have experience with valgrind -helgrind or other
  automated tools for finding potential deadlocks? @p{»»}

  @p{««}Running it on bitcoind I'm getting a huge number of false
  positives... @p{»»}

  @p{««}Should we just document every method that holds one or more locks?
  I'm worried there are other possible deadlocks lurking. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0741}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 13:55:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5011.msg73414@s{hash}msg73414
@section 3 {tx}

  @p{««}You can't see less-than-100-confirmation generations in
  listtransactions, but I agree, you should. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0742}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 17:51:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5011.msg73553@s{hash}msg73553
@section 3 {tx}

  @p{««}So... I'm working on a patch to add @p{lt}
  COINBASE_MATURITY-confirmation generation transactions to standard
  listtransactions, and trying to figure out the right way to handle
  immature generation transactions. @p{»»}

  @p{««}Either: @p{brk} a) list them as 'generate' @p{--} they'll just
  happen to have confirmations @p{lt} 100 (100 is the COINBASE_MATURITY,
  although the GUI doesn't show them until confirmations@s{gt}= 120).
  @p{»»}

  @p{««}b) list them as 'immature' @p{--} a new transaction category. @p{»»}

  @p{««}I'm leaning towards (b), because that way apps don't have to know
  that COINBASE_MATURITY is 100, and it is easier to double-check that
  listtransactions agrees with the getbalance API calls (immature coins
  are never counted in balances, because they can't be spent until they
  mature). @p{»»}

  @p{««}The only drawback I can think of is that adding a new transaction
  category might confuse existing code. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0743}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 19:21:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5011.msg73591@s{hash}msg73591
@section 3 {tx}

  @p{««}Pull request: @s{(link)} @p{»»}

  @p{««}From a testnet-in-a-box test, here's what mature/immature blocks
  look like: @p{»»}

  @s{code}
  
  @p{««} PS: There is a feature in the core bitcoin code that bothers me
  because I don't completely understand it: coinbase transactions are
  technically spend-able after 100 confirmations (COINBASE_MATURITY in the
  code), but they aren't counted as spendable by the GUI or the RPC until
  120+ confirmations (GetBlocksToMaturity() in the code). I suppose a big
  block-chain re-org could run into problems if a just-barely-mature
  generation was spent at exactly the wrong time, but I need to think
  about that a bit more (and maybe ping satoshi...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0744}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 19:39:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4981.msg73599@s{hash}msg73599
@section 3 {tx}

  @s{quotedtext}

  @p{««} Patches welcome. @p{»»}

  @p{««}But be aware that any patch that is vulnerable to denial-of-service
  attacks will be rejected, and I can't think of a way to automatically
  adjust the block size that wouldn't be vulnerable to some big,
  anti-social miner (think "jerk with a botnet") deciding it would be fun
  to artificially drive up transaction volume, drive up the block size,
  and create a few gigabytes of worthless blocks we all get to download
  forevermore. @p{»»}

  @p{««}When we get close to bumping into the block size limitation it will
  be @p{(it}easy@p{it)} to convince a majority of the network to
  upgrade@p{--} that's one problem that is obvious and easy to fix. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0745}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 20:20:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4936.msg73609@s{hash}msg73609
@section 3 {tx}

  @p{««}RE: botnets: if the botnet operator is economically rational, then
  their best strategy to make money is to just follow the rules, mine
  coins, and then sell them on the exchanges. @p{»»}

  @p{««}RE: the original poster's question on "can somebody with lots of
  money and a willingness to spend it to mess with the bitcoin exchange
  rate and cause fear, uncertainty and doubt" : @p{»»}

  @p{««}Yes. Yes, they can. That will be true while the bitcoin economy is
  small, and that is why I tell people not to 'invest' money in bitcoins
  that they can't afford to lose. @p{»»}

  @p{««}I still predict that there will be natural price bubbles and
  artificial ponzi schemes and all sorts of other things causing wild
  swings in the value of bitcoins. Next time I talk to an economist who
  knows something about currency markets I'll have to ask how big a
  currency has to be before it is mostly immune from speculative bubbles
  and price manipulation... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0746}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 20:21:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5011.msg73610@s{hash}msg73610
@section 3 {tx}

  @p{««}No, there is no 'mixed_debit' in my pull request. Coins are
  'immature' until they have 120+ confirmations, then they are 'generate'.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0747}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 20:25:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5019.msg73612@s{hash}msg73612
@section 3 {tx}

  @p{««}You're hired! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0748}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 22:28:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4995.msg73668@s{hash}msg73668
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... and also remember that command-line switches override values
  set in the bitcoin.conf file, so if you'd modified your Windows shortcut
  to -paytxfee that would stick. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0749}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-27 23:35:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5024.msg73697@s{hash}msg73697
@section 3 {tx}

  @p{««}What theymos said. Miners have a strong incentive to be
  well-connected (as do big merchants and exchangers and anybody else who
  generates or processes lots of transactions).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0750}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-28 11:59:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5058.msg73974@s{hash}msg73974
@section 3 {tx}

  @s{quotedtext}

  @p{««} If only somebody would create a @p{(link}really nice animated
  video@p{link)} explaining what bitcoin is....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0751}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-28 12:24:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5058.msg73987@s{hash}msg73987
@section 3 {tx}

  @p{««}eideteker: Can you ask the skeptics what we, the Bitcoin Community,
  could do to be less "smelly" or "sketchy" ? @p{»»}

  @p{««}I find people are much more sympathetic if instead of saying
  "What's your problem?" you instead ask "What am I doing wrong, and how
  can I fix it?" @p{»»}

  @p{««}And then you can get all jujitsu on them and praise their great
  ideas and gently suggest that you'd only screw up whatever it is they
  are suggesting (and you're busy doing other stuff already) so maybe they
  should just go ahead and do it... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0752}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 00:28:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5063.msg74400@s{hash}msg74400
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... and we're looking for volunteers. See @s{(link)} @p{»»}

  @p{««}Quick "why no proper SSL cert" : because it never made it near the
  top of anybody's TODO list. The task is: @p{»»}

    @p{(li}@p{(li} Figure out where the bitcoin.org domain is registered
    and make sure the MX records/etc are pointing somewhere so
    verification emails from the certificate authority don't get lost.
    @p{li)} @p{(li} buy the cert and jump through the 'verify you are who
    you say you are' hoops. @p{li)} @p{(li} replace the self-signed cert
    on the web server @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0753}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 14:23:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5019.msg74828@s{hash}msg74828
@section 3 {tx}

  @s{quotedtext}

  @p{««} So one of my pet peeves is the United States Legal System. @p{»»}

  @p{««}It has lots of rules. The problem is nobody can possibly read them
  all. And yet "ignorance of the law is no excuse!" @p{»»}

  @p{««}I'm a big fan of a few general, fuzzy rules and common sense. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0754}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 16:05:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4983.msg74911@s{hash}msg74911
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think that's the right way to think about it. And I think Jeff
  actually implementing a straw-man proposal is exactly the right thing to
  do. @p{»»}

  @p{««}So: I say we don't try to defend against (3), at least not right
  now. If you have root then you can install a keylogger, read memory,
  intercept any system call, etc etc etc. (I would like to see somebody
  implement a bitcoin client that required payment verification using a
  cell phone app or telephone call or PIN-sent-to-email and did all the
  magic key management to make that work securely, but I think that's
  beyond the scope of what we can reasonably do right now). @p{»»}

  @p{««}Defending against (1) and (2) would help with: @p{»»}

  @p{««}a) you forget to logout so attacker sits down at your computer,
  starts bitcoin and empties your wallet. @p{li)}

  b) attacker gets a hold of a filesystem backup that is not encrypted.
  @p{li)}

  c) sysadmin sets file permissions incorrectly so attacker on multi-user
  system can read your wallet.dat @p{li)}

  d) attacker guesses or finds out your ssh password, logs in remotely and
  steals your wallet.dat. @p{»»}

  @p{««}It won't help with: @p{brk} - sysadmin with root privileges is evil
  @p{li)}

  - system compromised by rootkit/trojan/keylogger @p{»»}

  @p{««} RE: encrypt everything: I say maybe later. Just encrypt everything
  isn't trivial: users would have to wait a minute or two or ten for
  Berkeley DB to rewrite all of blkindex.dat (bottleneck will be disk I/O,
  not the encryption), and we have to deal with "my disk filled up when I
  changed my password, things are half-encrypted and half-not, what do I
  do now?" And I don't see a lot of value in encrypting all of wallet.dat;
  forget to shutdown bitcoin and an attacker that wants to know your
  public addresses can just open up the address book and take a
  screenshot.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0755}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 16:17:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5125.msg74923@s{hash}msg74923
@section 3 {tx}

  @p{««}Feature request is here: @p{(link}@s{(link)}@s{hash}issue/14@p{link)} 

# ----------------------------------------------------------------------
@section 2 {ms0756}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 16:38:29 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5140.msg74940@s{hash}msg74940
@section 3 {tx}

  @p{««}yes 

# ----------------------------------------------------------------------
@section 2 {ms0757}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-29 23:44:10 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5147.msg75185@s{hash}msg75185
@section 3 {tx}

  @p{««}ClearCoin requires 3 confirmations before coins are available to be
  released; the sender will see something like: @p{»»}

  @s{quotedtext}

  @p{««}... while they're in the process of being confirmed. @p{»»}

  @p{««}I'll change the receiver's status page so it shows the amount
  awaiting confirmation, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0758}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 12:51:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5171.msg75553@s{hash}msg75553
@section 3 {tx}

  @p{««}All this endless talking about the Perfect URI Scheme is very nice.
  @p{»»}

  @p{««}So is anybody, you know, actually working on IMPLEMENTING
  something? @p{»»}

  @p{««}You'll need to know how to write browser plugins for
  Firefox/Safari/Chrome/IE and figure out how to pass arguments to a
  running bitcoin/bitcoind and know how the bitcoin/bitcoind will prompt
  the user to confirm the transaction. Oh, and figure out how to get the
  browser plugin(s) installed when bitcoin is installed. @p{»»}

  @p{««}Deciding on whether it is bitcoin:address or
  bitcoin://amount/address is the easy part, and I think whoever actually
  does the work of making this happen should define the standard. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0759}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 15:04:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5187.msg75619@s{hash}msg75619
@section 3 {tx}

  @p{««}So before deciding to do ClearCoin, I was thinking I was going to
  clone one or more of the PayPal shopping cart / payment APIs. @p{»»}

  @p{««}The advantage would that all of the existing shopping cart
  interfaces that know how to talk to PayPal would "just work" with
  bitcoins (the PayPal APIs can already deal with multiple currencies)
  @p{--} just replace the @s{(link)} URL (or whatever it is) and specify
  amounts in BTC instead of USD or EUR. @p{»»}

  @p{««}The short-term business model would be an E-Wallet for businesses
  (like PayPal). The medium/long-term business plan would be to get
  acquired by PayPal when PayPal decided they need to support bitcoin.
  @p{»»}

  @p{««}If you don't like PayPal, then replace "PayPal" by "Google
  Checkout" or whatever other, popular payment processing gateway API is
  already being used by lots of websites. @p{»»}

  @p{««}I still think this is a good idea, but I'm busy, so I'm throwing it
  out here and hoping somebody decides to do it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0760}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 15:57:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5188.msg75651@s{hash}msg75651
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's not part of the official API, that's just a fun hack I made
  one day on a whim. @p{»»}

  @p{««}The technical information in the wiki needs more attention and
  polish; if you have time and are a decent writer, please jump in and
  help out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0761}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 17:11:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg75698@s{hash}msg75698
@section 3 {tx}

  @p{««}Can you'all educate me about these mythical rounding errors that
  require using GMP? @p{»»}

  @p{««}I can see, maybe, if you're computing interest down to the penny on
  a 30-year mortgage you might conceivably be off by a penny if you use
  64-bit floats instead of 64-bit integers, although even there you're
  going to have to think hard about rounding as you get integer
  remainders. @p{»»}

  @p{««}And I can see being really careful if you're writing a bitcoin
  exchange site or bitcoin bank that deals in thousands of internal
  transactions that must all balance exactly. @p{»»}

  @p{««}But for the typical PHP website that is just going to add up 10
  items in a shopping cart using plain-old PHP Numbers will be just fine.
  I don't see PayPal recommending that PHP users of it's APIs install GMP.
  Recommending that any website dealing with bitcoins compile genjix' fork
  and use GMP is a really good way to ensure that nobody accepts bitcoins.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0762}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 18:22:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg75744@s{hash}msg75744
@section 3 {tx}

  @p{««}Apologies to Nefario, I was reacting to the wiki pages written by
  genjix on how to use PHP with bitcoind that started with: @p{»»}

  @p{(li}  First, compile my fork.  @p{li)}

    @p{(li}@p{(li} Next, install the GMP and BCMath libraries... @p{li)}

  @p{««}And why do I defend floats: because simple things should be simple.
  Using GMP/BCMATH is overkill for 98% of what bitcoin JSON-RPC users will
  be doing. @p{»»}

  @p{««}And because certain people keep beating this dead horse. I have
  said that I am PERFECTLY WILLING to support strings in the JSON-RPC
  interface if somebody can demonstrate to me someplace where it is
  actually a real problem (that isn't trivially solved using something
  like round(value*1e8+0.5) or printf("%.08", value)). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0763}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 18:29:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg75750@s{hash}msg75750
@section 3 {tx}

  @s{quotedtext}

  @p{««} People keep claiming that, and yet I just did YET ANOTHER google
  search for "banking apis", clicked through to the Open Financial
  Exchange standard (from Microsoft and Quicken), and what do you know!
  Money amounts look like floats: @p{»»}

  @p{««} Code: @p{lt}STMTTRN@s{gt} @p{»»}

    @p{(li} @p{lt}TRNTYPE@s{gt}CREDIT @p{li)}

    @p{(li} @p{lt}DTPOSTED@s{gt}20070315 @p{li)}

    @p{(li} @p{lt}DTUSER@s{gt}20070315 @p{li)}

    @p{(li} @p{lt}TRNAMT@s{gt}200.00 @p{li)}

    @p{(li} @p{lt}FITID@s{gt}980315001 @p{li)}

    @p{(li} @p{lt}NAME@s{gt}DEPOSIT @p{li)}

    @p{(li} @p{lt}MEMO@s{gt}automatic deposit @p{li)}

    @p{(li} @p{lt}/STMTTRN@s{gt} @p{li)}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0764}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 18:38:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg75758@s{hash}msg75758
@section 3 {tx}

  @p{««}All righty, I hereby state: @p{»»}

  @p{««}All money values in the bitcoin JSON-RPC interface Are and Shall Be
  treated as Decimal, with 8 digits of precision after the decimal point.
  @p{»»}

  @p{««}If you're writing a banking application in a language that doesn't
  support Decimal types from JSON, then you should pack up your bags and
  go home. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0765}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-30 19:18:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg75783@s{hash}msg75783
@section 3 {tx}

  @s{quotedtext}

  @p{««} An IEEE double-precision floating point number has 53 bits of
  precision, which IS sufficiently accurate to store a bitcoin balance.
  @p{»»}

  @p{««}Every single possible bitcoin value can be converted to and from an
  IEEE 64-bit float with no loss of precision. @p{»»}

  @p{««}I agree that if you're going to be performing lots of calculations
  on bitcoin values you need a Decimal type (and ClearCoin stores and uses
  python's decimal.Decimal(precision=8) for all bitcoin values)@p{--} if
  you don't, floating point errors can accumulate and eventually cause you
  to gain or lose .00000001 of a coin. @p{»»}

  @p{««}But really the main problem with storing monetary values as any
  floating point type is you're likely to be embarrassed by mistakes like
  error's cash register receipt if you truncate values instead of rounding
  before printing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0766}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-03-31 12:04:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg76297@s{hash}msg76297
@section 3 {tx}

  @s{quotedtext}

  @p{««} HOW MANY TIMES DO I HAVE TO YELL THIS?@s{huh}?? @p{»»}

  @p{««}Of COURSE you shouldn't use floats internally (unless you are doing
  something trivial like adding up items in a shopping cart). @p{»»}

  @p{««}We are talking about the JSON-RPC api. Which is an api for
  communicating between bitcoin and other applications, in which all
  values are turned into strings. @p{»»}

  @p{««}So: what are the best practices in the banking world for
  representing monetary values in strings? As far as I can tell, the
  answer is "write them out as decimal values and convert them to
  Decimal() or integer as you read in or write out." @p{»»}

  @p{««}Which is exactly what Bitcoin does, and which is what I think we
  should recommend to people. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0767}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-01 11:58:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4086.msg77055@s{hash}msg77055
@section 3 {tx}

  @s{quotedtext}

  @p{««} Am I the only person here who looks at our documentation for how
  to use bitcoin from PHP and thinks "people are going to run away
  screaming" ? See: @p{(link}@s{(link)}(JSON-RPC)@p{link)} @p{»»}

  @p{««}I @p{(bf}strongly@p{bf)} believe you are making the common cases
  (simple shopping carts or "hold a bitcoin balance for a customer and let
  them spend it") much, much more complicated than necessary. @p{»»}

  @p{««}What do other people think? I'd especially like to hear from people
  who have prior experience using PHP to implement shopping carts and
  other simple applications that deal with money. Did you use BCMATH/GMP?
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0768}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-01 13:37:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5276.msg77098@s{hash}msg77098
@section 3 {tx}

  @p{««}Adds support for the Tonal numbering system to bitcoin. Branch is
  at @s{(link)} @p{»»}

  @p{««}Pull request is: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}59865;@p{link)} @p{li)}

  @p{««}(Note: you will need Tonal Git and a Tonal-capable browser to
  follow that link). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0769}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-01 14:12:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5278.msg77118@s{hash}msg77118
@section 3 {tx}

  @p{««}From @p{(link}wikipedia@p{link)}: @p{»»}

  @s{quotedtext}

  @p{««} So, who are the merchants in the bitcoin rush?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0770}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-02 19:24:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5324.msg77896@s{hash}msg77896
@section 3 {tx}

  @p{««}Cloning your wallet to do anything besides backing it up is a bad
  idea. @p{»»}

  @p{««}It might work perfectly for a while... but you are very likely to
  get weird behavior from bitcoin sooner or later, because doing that is
  not tested or supported. @p{»»}

  @p{««}Where 'weird behavior' is one clone of the wallet shows one
  balance, the other clone shows another, and you might end up with
  bitcoins that you can spend from one wallet but not the other (or, worst
  case, end up with bitcoins that neither wallet is able to spend). @p{»»}

  @p{««}If you REALLY REALLY REALLY want to do this... then get the latest
  code from git, pull sipa's 'Spent per txout' patch, and then spend a
  bunch of time testing to find out what happens when your cloned wallets
  eventually start using different keys from the keypool. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0771}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-03 14:59:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5227.msg78144@s{hash}msg78144
@section 3 {tx}

  @p{««}I just bought two Boston Red Sox tickets from my friend Baer using
  bitcoins. They really do work nicely for grassroots, person-to-person
  transactions, and the beautiful thing is you don't need a lot of people
  accepting them in one place to get started. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0772}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-03 23:31:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5348.msg78385@s{hash}msg78385
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's not the ONLY question. A question I've been thinking a lot
  about is what are an employer's potential liabilities if they are caught
  paying employees in bitcoins "under the table." @p{»»}

  @p{««}I honestly don't know the answer if the employer is in Finland and
  the employee is in Ecuador, and suspect the answer might depend on
  whether or not the person doing the work is considered an independent
  contractor or an employee. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0773}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-05 00:00:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5387.msg79185@s{hash}msg79185
@section 3 {tx}

  @p{««}Do these types of 'make money without doing anything productive'
  schemes bother anybody else, or am I just a financial prude who doesn't
  recognize harmless fun when I see it? @p{»»}

  @p{««}I feel like we might soon need a Frequently Seen Schemes to go
  along with our FAQ, just to let people know that using a different
  currency doesn't suspend the laws of economics. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0774}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-05 12:04:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5324.msg79519@s{hash}msg79519
@section 3 {tx}

  @s{quotedtext}

  @p{««} Better would be a new feature that tells the mining bitcoin
  "please credit generated bitcoins to THIS address (instead of a new
  one)." @p{»»}

  @p{««}If you are just mining, you don't need the private key at all, the
  bitcoin address (or public key) is enough to create the coin generation
  transaction.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0775}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-06 13:32:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5422.msg80354@s{hash}msg80354
@section 3 {tx}

  @p{««}Be nice, y'all. Todd emailed me directly and I steered him here
  because I don't have time to talk about economic theory with everybody
  who emails me these days. @p{»»}

  @p{««}Todd: if you were designing a new currency, what would it look
  like? Are you imagining a LETS-like system of credit? @p{»»}

  @p{««}Bitcoin is designed to be like a scarce natural resource, which is
  pretty conservative, really@p{--} scarce natural resources have a long
  history of being used as currency. I don't know enough about the
  alternatives to know whether or not they could work as an Internet
  currency@p{--} the LETS systems I've heard about all rely on local
  interactions and trust to keep people from cheating. @p{»»}

  @p{««}PS: I'm going to move this thread to the Economics forum. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0776}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-06 13:40:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5475.msg80357@s{hash}msg80357
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, and right now it will sit in your wallet at 0 confirmations
  and get rebroadcast once in a blue moon (ok, not that long, but I'm too
  lazy right now to dig out the rules for when transactions are
  rebroadcast) until it DOES make it into a block. @p{»»}

  @p{««}And you'll have to hack your copy of bitcoin to be able to send a
  less-than-.01 transaction without a fee; the RPC send* methods
  automatically add the fee, and the GUI will tell you a fee is necessary
  (and won't let you send unless you agree to it). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0777}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-06 13:43:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5333.msg80360@s{hash}msg80360
@section 3 {tx}

  @p{««}I added a comment to the PULL request@p{--} I ran into an issue
  when sanity testing this (a testnet wallet that reports an impossibly
  high balance after conversion). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0778}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-06 13:53:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5485.msg80366@s{hash}msg80366
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}I think this is ready: @s{quotedtext}

  @p{««} I found one edge case during testing, and after discussion on
  @s{hash}bitcoin-dev changed the information reported. The edge case was
  reporting the coinbase transactions from orphaned blocks. Here's the
  scenario: @p{»»}

  @p{(li}  As soon as you generate a block, the coinbase transaction goes
  into your wallet as a 1-confirmation transaction. Before this patch,
  that transaction was not listed in the listtransactions output. With
  this patch, it is (as "category" : "immature", "confirmations" : 1).
   @p{li)}

  @p{(li}  If that block is orphaned, the coinbase transaction is no longer
  valid. With this patch, it will be reported at "category" : "orphan",
  "confirmations" : 0  @p{li)}

  @p{(li}  When a coinbase transaction has 120 confirmations, it will be
  reported as "category" : "generate" (as before).  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0779}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-07 23:27:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5540.msg81541@s{hash}msg81541
@section 3 {tx}

  @p{««}Stuff is valuable because it is either useful (like hammers) or we
  think it is pretty (like Picasso paintings); the more rare, useful,
  and/or desirable something is, the more valuable it tends to be. @p{»»}

  @p{««}We know how rare bitcoins are. It remains to be seen how useful
  they are. I think they're pretty useful as both a convenient way of
  paying for things and as a long-term store of value, but it will take
  time to convince most people that they're useful for those things. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0780}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 12:51:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5567.msg81975@s{hash}msg81975
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh. One-to-three @p{(bf}day@p{bf)} transfer times doesn't seem to
  have hurt the dollar much: @s{(link)} @p{»»}

  @p{««}"Instant" payments with world currencies is an illusion created by
  your bank of financial institution based on how much they trust the
  person or institution sending the money. There is nothing stopping
  bitcoin financial institutions from using the same trick, and I think as
  the bitcoin economy grows and companies start to trust each other
  instant transfer times will happen. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0781}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 18:06:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5549.msg82138@s{hash}msg82138
@section 3 {tx}

  @p{««}Limit-per-ip-range is an interesting idea. @p{»»}

  @p{««}I'd like to give the current not-yet-released solution a month or
  two to work before trying something else. I see two possible directions:
  @p{»»}

  @p{««}@s{code} Trouble with this is an attacker
  who has multiple IPs (think botnet operator) can mount a distributed
  flood attack. @p{»»}

  @p{««}or/and @p{»»}

  @p{(li}  Take transaction priority into account when deciding what to
  drop.  @p{li)}

  @p{««}I'd really like to talk to a p2p network researcher; it seems to me
  it might be possible to keep some statistics on what "typical" bitcoin
  network traffic looks like; perhaps nodes could drop neighbors if they
  notice network traffic from them looks way out of whack (e.g. sending a
  much-larger-than-typical number of addr messages or free transactions
  or...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0782}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 18:18:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5579.msg82150@s{hash}msg82150
@section 3 {tx}

  @s{quotedtext}

  @p{««} Hundreds of google accounts AND hundreds of IP addresses (the
  Faucet does still check IP address). And the patience to solve hundreds
  of CAPTCHAs... @p{»»}

  @p{««}I'm pretty sure almost all of the bitcoins going out of the Faucet
  are new people trying out Bitcoin. We're getting between 500 and 1,000
  downloads of bitcoin binaries from the SourceForge site per day
  (@p{(link}stats here@p{link)}). @p{»»}

  @p{««}PS: Thanks again to everybody who donates to keep the Faucet
  running! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0783}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 18:57:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5587.msg82187@s{hash}msg82187
@section 3 {tx}

  @p{««}I'll be in Paris with my family next month, and would like to
  arrange a meeting or two with other bitcoin-people. Who is in/near
  Paris, and what would be a good time/place to meet? @p{»»}

  @p{««}PS: sorry for not writing in French, it has been a very LONG time
  since high-school French class... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0784}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 20:23:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5573.msg82230@s{hash}msg82230
@section 3 {tx}

  @s{quotedtext}

  @p{««}... only if the investments are in things that don't make us more
  productive. @p{»»}

  @p{««}There are really three categories, in order of desirability: @p{»»}

  @p{««}1 Investment in productive activities @p{li)}

  2 Savings @p{li)}

  3 Investment in non-productive activities @p{»»}

  @p{««}The broken window fallacy is confusing categories 1 and 3.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0785}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-08 23:00:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5549.msg82315@s{hash}msg82315
@section 3 {tx}

  @s{quotedtext}

  @p{««} The problem with that idea is if the transaction fee is that low
  spammers won't notice it either. They can just invest 0.01 BTC and send
  millions of "non-free" transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0786}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-09 15:53:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5619.msg82695@s{hash}msg82695
@section 3 {tx}

  @p{««}What is meant by "rather inefficient"? Speed of
  serializing/deserializing? @p{»»}

  @p{««}I can't imagine that is a significant factor for communicating with
  bitcoin; if you're running into JSON-RPC bottlenecks (is anybody running
  into performance bottlenecks due to JSON-RPC yet? If you are, what are
  you doing?) then the lack of persistent connections, lack of
  JSON-RPC-2.0-multicall support, or bitcoin single-threaded RPC are
  likely much, much bigger issues. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0787}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-09 16:22:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5549.msg82711@s{hash}msg82711
@section 3 {tx}

  @p{««}Transaction spam is not a high-priority issue, in my humble
  opinion, and I don't think we need to do anything more right now. @p{»»}

  @p{««}We were running into big free-transaction backlogs because of the
  rise in popularity of the mining pools, but with the big pools now using
  the new sendmany feature to pay (with a transaction fee) their users
  that issue has gone away. @p{»»}

  @p{««}The improved -limitfreerelay and sendmany will both be in the next
  release, which should further improve the situation. And I think in the
  next few months lightweight download-headers-only clients will start to
  appear. @p{»»}

  @p{««}I would much rather see work on optimizing the network protocol so
  that hashed of already-spent transactions deep in the block chain aren't
  sent to (or stored on) new nodes joining the network. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0788}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-09 16:25:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5606.msg82712@s{hash}msg82712
@section 3 {tx}

  @p{««}GMT is always +0:00, so why not hardcode that instead of using %z
  or %Z? @p{»»}

  @p{««}RE: changing locale: good idea.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0789}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-09 16:30:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5176.msg82716@s{hash}msg82716
@section 3 {tx}

  @p{««}Kel'Thuzad, US. But I haven't played much since my 85 Warlock got
  the "Explorer" title.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0790}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-10 16:05:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5634.msg83363@s{hash}msg83363
@section 3 {tx}

  @p{««}0.3.20.1 -maxsendbuffer was too small for the initial block
  download@p{--} you were probably just unlucky and connected to a
  0.3.20.1 node. Connect to somebody running either 0.3.20.2 or an earlier
  release and you won't run into that problem (does bitcoinj re-connect if
  disconnected during block download?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0791}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-10 16:23:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5540.msg83373@s{hash}msg83373
@section 3 {tx}

  @s{quotedtext}

  @p{««} In 2009: @s{quotedtext}

  @p{««} @p{(link}Source@p{link)} @p{brk} All mobile phones will be
  internet-enabled in 10 years, and I think it is pretty safe to assume
  that most people on the planet will have some access. It won't surprise
  me if bitcoin first goes mainstream in an up-and-coming third-world
  country or region. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0792}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-10 18:41:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5648.msg83425@s{hash}msg83425
@section 3 {tx}

  @p{««}I can't see how it could work. If I knew my LunaCoin balance was
  going to be reset at midnight and it is 1 minute to midnight, I'd be
  crazy to accept them. Reason backwards from there and I don't see how
  you could possibly have a stable economy, at least not in the last few
  days leading up to the reset. People would try like crazy to get rid of
  their LunaCoins, and it would get harder and harder to find somebody
  willing to take them. @p{»»}

  @p{««}TiagoTiago asked if anything like "reset everybody's balance at the
  beginning of every month" has ever been tried, and it reminds me of
  historical @p{(link}debt relief@p{link)}, where all debts are forgiven
  every N years, usually by people of a certain religious background.
  @p{»»}

  @p{««}If I recall correctly, people were very creative about finding ways
  to get around it, but I don't have any references handy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0793}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-11 02:14:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5400.msg83600@s{hash}msg83600
@section 3 {tx}

  @p{««}I'd rather see more non-technical bitcoin-related videos rather
  then "this is what the block chain looks like" technical videos. @p{»»}

  @p{««}I'm going to brain dump some half-baked thoughts: @p{»»}

  @p{««}So I watched @p{(link}this talk by Jonathan Haidt@p{link)} on the
  moral roots of liberals and conservatives and started thinking about how
  it might apply to more mainstream acceptance of Bitcoin. If Jonathan is
  right, then I think conservatives will find reasons to hate bitcoin, but
  liberals might be convinced to love it. @p{»»}

  @p{««}So what are the videos that liberals love? Well, there's
  @p{(link}The Story of Stuff@p{link)}, which @p{(link}I think is
  wrong-headed@p{link)} but is incredibly popular. @p{»»}

  @p{««}I'd like to see a video targeted towards left-leaning people that
  argues from their world-view@p{--} why the existing monetary system is
  unfair and benefits a rich elite at the expense of the working masses.
  How Bitcoin can change that and be a People-Powered money, backed not by
  empty promises from rich bankers but by the strength and trust of the
  person-to-person Bitcoin Community. How friends and neighbors using
  Bitcoin can keep money in local communities. How using Bitcoin lets you
  interact with people all over the world, promoting peace and
  understanding. How it is better for the environment than gold mining or
  trucking coins and cash to and from stores and banks. @p{»»}

  @p{««}Of course, early adopter libertarian-leaning bitcoiners will
  probably HATE it, but they wouldn't be the target audience...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0794}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-12 13:46:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5721.msg84392@s{hash}msg84392
@section 3 {tx}

  @s{quotedtext}

  @p{««} That sounds overly complicated. Does your ruby/json implementation
  have double-precision (64-bit) floats? If it does, just multiply by
  1.0e8 and rounding to the nearest integer. @p{»»}

  @p{««}Quick way to tell if your ruby implementation does 64-bit floats:
  see what you get converting 21000000.00000001*1e8 to an integer.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0795}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-12 21:12:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5579.msg84615@s{hash}msg84615
@section 3 {tx}

  @s{quotedtext}

  @p{««}Neat idea@p{--} I've been thinking about how to let
  people/companies sponsor the Faucet. @p{»»}

  @p{««}The next couple of things on my TODO list are getting the 0.3.21
  bitcoin release process started and an API for ClearCoin, but I might
  tackle Faucet donations after those are done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0796}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-13 13:13:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5769.msg85007@s{hash}msg85007
@section 3 {tx}

  @p{««}One address per client is a good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0797}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 01:54:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5752.msg85484@s{hash}msg85484
@section 3 {tx}

  @p{««}I can see the GUI not allowing a less-than-CENT to save
  fat-fingered users from themselves, but I think the RPC should allow it;
  at the very least it makes it possible for a kind of grass-roots
  movement to arise between miners and people generating transactions so
  if we start seeing a lot of transactions with
  less-than-CENT-per-kbyte-fees then that's a really good indication the
  default definition of "free" needs to change. @p{»»}

  @p{««}And now that the RPC and GUI allow full-precision amounts for
  send/move, there is no problem with "I got 50.000001 bitcoins from
  mining, how do I send ALL of them?" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0798}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 12:31:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5819.msg85729@s{hash}msg85729
@section 3 {tx}

  @p{««}I've turned off the faucet; somebody is definitely stealing from
  it. There were 500 sends queued when I woke up this morning. @p{»»}

  @p{««}They are using a different IP address, different google account,
  and are even changing the browser ID string on every request@p{--} here
  are three entries from the request log, for example: @p{»»}

  @s{code}

  @p{««} "zqdckyxnhmjj" and "clkjqwbhwefj" are the google account logins,
  which are obviously bogus. Well, obvious to humans, anyway...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0799}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 13:40:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5819.msg85755@s{hash}msg85755
@section 3 {tx}

  @p{««}That pattern is definitely the faucet. The big mining pools are
  already using the new 'sendmany' functionality to pay lots of people
  with one transaction. @p{»»}

  @p{««}I'm thinking of doing something similar for the Faucet. Perhaps:
  @p{»»}

  @p{(li}  Bundle up requests for payments, so instead of sending out
  payment right away you have to wait a bit (15 minutes or an hour or...
  something somewhat random and non-predictable).  @p{li)}

  @p{(li}  Dropping the Faucet reward AGAIN so there is less incentive to
  cheat. I'll need to use sendmany so the faucet isn't paying as much in
  fees as it is in bitcoins it gives out.  @p{li)}

  @p{««}And maybe: @p{»»}

  @p{(li}  Publicly display the queue of waiting requests. This would be the
  tricky part@p{--} I don't want to just dump email address and IP
  address, but I do want to dump enough information so people looking at
  the information can tell the difference between a cheater and legitimate
  users.  @p{li)}

  @p{(li}  A way of flagging requests as "looks like cheating to me". This
  is also hard@p{--} griefers might decide it would be fun to flag lots of
  legitimate requests.  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0800}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 15:55:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5827.msg85827@s{hash}msg85827
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm not really ugly, am I? You should have seen me in college when
  I was too cheap to get a haircut... @p{»»}

  @p{««}So: bitcoind doesn't ask for confirmation before sending fees with
  a transaction because it is was much easier to implement that way, and
  for most uses of bitcoind paying an occasional transaction fee isn't a
  problem. @p{»»}

  @p{««}If you'd like to help fix it, patches are welcome. I think a new
  setting that says "don't pay more than N bitcoins for any transaction
  without asking me" and a new argument to the send routines to say either
  "I'm willing to pay up to X bitcoins for this transaction" or "I want to
  pay X bitcoins in transaction fees with this transaction" is a good
  idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0801}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 16:36:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5815.msg85847@s{hash}msg85847
@section 3 {tx}

  @s{quotedtext}

  @p{««} If you figure out a cheat-proof, distributed, fair way of doing
  that please let me know. I need that magical solution for the Bitcoin
  Faucet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0802}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 17:04:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5815.msg85866@s{hash}msg85866
@section 3 {tx}

  @s{quotedtext}

  @p{««} That fails the fairness test, too@p{--} identical twins won't get
  their fair share.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0803}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-14 18:31:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5819.msg85930@s{hash}msg85930
@section 3 {tx}

  @p{««}RE: paying somebody to monitor the faucet: good idea, although I
  like the idea of some kind of "community watch" more. And monitoring the
  Faucet is an all-day-and-night, all-the-time kind of job. And if the
  scammers are willing to try to drain the faucet slowly then they could
  create accounts with more realistic-looking names and would be able to
  sneak by the monitors... @p{»»}

  @p{««}RE: just using testnet coins: I worry about people starting to
  trade testnet coins, giving them real value. Giving lots of newbies who
  don't really understand bitcoin testnet coins seems like a really good
  way to make that happen! @p{»»}

  @p{««}RE: proof-of-work before getting coins: Interesting idea! Some
  JavaScript in-the-browser proof-of-work that required keeping the 'get
  some' page open for a minute or six might make the cost to the scammers
  high enough that the bitcoin reward wouldn't be worth it. @p{»»}

  @p{««}RE: looking at the google account creation date: that information
  isn't available to the Faucet's code (unless I'm missing something in
  the Google App Engine API). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0804}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-15 01:52:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1271.msg86186@s{hash}msg86186
@section 3 {tx}

  @s{quotedtext}

  @p{««} As of version 0.3.20, the GUI and JSON-RPC both allow
  full-precision values for sends. So you can send 1.00123456 BTC if you
  like. @p{»»}

  @p{««}And the GUI will display full-precision wallet balances/etc (it
  truncates trailing zeros past .00, so you won't notice unless you have
  sub-cent BTC in your wallet). @p{»»}

  @p{««}The 'dust spam' rules are still in, so you're expected to pay a fee
  if you are sending less than 0.01 BTC@p{--} that is, if you try to send
  0.00001 BTC it will trigger the fee (sending 1.00001 would not trigger
  the fee). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0805}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-15 13:49:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5809.msg86492@s{hash}msg86492
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, they don't. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0806}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-15 17:20:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1271.msg86659@s{hash}msg86659
@section 3 {tx}

  @p{««}You're right@p{--} full-precision is in git-head, but wasn't in
  0.3.20. It will be in 0.3.21. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0807}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-16 13:22:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5909.msg87270@s{hash}msg87270
@section 3 {tx}

  @p{««}There are actually a few different ways to get a negative account
  balance. @p{»»}

    @p{(li} 1. As theymos said, the "" account is special, and can go
    negative if you use sendtoaddress instead of sendfrom. @p{li)}

    @p{(li} 2. Other accounts can go negative if they receive coins on a
    bitcoin address, you send those coins from that account, and then you
    use setaccount to re-assign those received coins to some other
    account. @p{li)}

    @p{(li} 3. They can also go negative by the transaction fee amount if
    you sendfrom the coins in an account and the send needs a transaction
    fee. @p{li)}

  @p{««}Also as theymos says, you can never send more coins than are in
  your total wallet. And it should ALWAYS be true that the sum of coins in
  all accounts equals the number of coins you can send. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0808}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-17 14:09:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5888.msg88012@s{hash}msg88012
@section 3 {tx}

  @p{««}It always bothered me that the MySQL's SELECT... LIMIT statement
  could skip records if the database was changing between calls, but that
  doesn't seem to bother anybody else. @p{»»}

  @p{««}This patch is very much like MySQL LIMIT, is needed for the same
  reason (paging through results efficiently in a GUI), is backwards
  compatible, and looks good to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0809}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-18 23:42:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5819.msg89236@s{hash}msg89236
@section 3 {tx}

  @p{««}Thanks for the suggestions and comments, everybody; I think a
  combination of dropping the faucet reward again (I'll start bundling up
  faucet payments into 'sendmany' transactions, so the transaction fees
  are lower) and "community watch program" will work. @p{»»}

  @p{««}The 'community watch' will be a web page that anybody can see that
  shows the last 100 IP addresses that got payments along with an
  obfuscated version of the email address (I'll obfuscate by randomly
  turning an email address like
  '@p{(link}gavinandresen@s{at}gmail.com@p{link)}' into
  '@p{(link}gavniadresen23@s{at}gmail.com@p{link)}'). And I'll recruit some
  trusted people and give them access to a master faucet shut-off switch
  if it starts getting abused again. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0810}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-19 01:11:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3612.msg89305@s{hash}msg89305
@section 3 {tx}

  @s{quotedtext}

  @p{««} When you launch your instance, make sure the firewall ("Security
  Group" in AWS-speak) is setup to allow remote desktop access from your
  machine's IP address to port 3389. @p{»»}

  @p{««}I run Remote Desktop Client on my Mac, but the process should be
  the same on PC. @p{»»}

  @p{««}Connect using the "Public DNS" machine name@p{--} something like:
  ec2-184-2-91-236.compute-1.amazonaws.com @p{»»}

  @p{««}Login as Administrator, password: bitcoin development @p{»»}

  @p{««}(I just launched the 0.3.20.2 Windows AMI to get ready to build a
  0.3.21 release candidate). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0811}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-19 02:05:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6029.msg89333@s{hash}msg89333
@section 3 {tx}

  @s{quotedtext}

  @p{««} I pulled a patch that makes Linux/Mac bitcoin/bitcoind write a
  bitcoind.pid file when started with the -daemon switch (and erases it on
  shutdown). @p{»»}

  @p{««}Next release will have several changes to make startup on Linux/Mac
  more unix-standard-like. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0812}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-19 02:16:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6076.msg89347@s{hash}msg89347
@section 3 {tx}

  @p{««}It might make more sense to allow non-sensitive RPC commands to
  function without a password. Where "non-sensitive" would be
  getblockcount/getdifficulty maybe getnewaddress/getaccountaddress and a
  new 'you clicked on a bitcoin: URI so popup a payment confirmation
  dialog'. @p{»»}

  @p{««}"Making it easier for other applications to integrate with bitcoin"
  is bad if the other applications are trying to steal your wallet, so I'm
  reluctant to have bitcoin do things like create passwords for users.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0813}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-19 02:40:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6076.msg89362@s{hash}msg89362
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yup, although I'd like more brains to think it through@p{--} are
  there any potential denial-of-service attacks if bitcoin is listening
  for RPC commands by default (note that JavaScript in your web browser
  CAN access @s{(link)}, the same-origin-policy for JavaScript doesn't
  apply to localhost URLs)? @p{»»}

  @p{««}Does it open up any extra security holes if you're on a multi-user
  system? @p{»»}

  @p{««}And I don't think it should go into mainline bitcoin until there is
  a compelling need for it@p{--} and I don't think there will be a need
  until the 'click on a link, popup payment dialog from bitcoin'
  functionality is worked out... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0814}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-19 12:49:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6082.msg89608@s{hash}msg89608
@section 3 {tx}

  @p{««}Run the gui with the -server switch. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0815}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 02:13:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6136.msg90111@s{hash}msg90111
@section 3 {tx}

  @p{««}Nope, penny-flooder.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0816}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 13:11:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6167.msg90473@s{hash}msg90473
@section 3 {tx}

  @p{««}It is a Berkeley DB binary database file. @p{»»}

  @p{««}@s{(link)} has fairly easy to read python code for parsing it@p{--}
  see @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0817}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 13:30:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6159.msg90482@s{hash}msg90482
@section 3 {tx}

  @s{quotedtext}

  @p{««} The 0.3.21 release (I hope to have a release candidate available
  today) will support full-precision values@p{--} you will be able to send
  1.00123456 BTC, if you like. @p{»»}

  @p{««}Sending less than 0.01 BTC still requires a 0.01 BTC fee, though.
  Changing that to "sending less than 0.01 BTC requires a 0.001 BTC fee"
  might be worth thinking about, but I think there are higher priorities
  on the core bitcoin TODO list. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0818}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 15:31:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6178.msg90534@s{hash}msg90534
@section 3 {tx}

  @p{««}This is a single-line change that allows non-standard transactions
  to get into the transaction memory pool (and, therefore, relayed and
  written into blocks) on -testnet. @p{»»}

  @p{««}Satoshi suggested this to me in an email a few weeks ago, and I
  agree it is a good idea@p{--} we should encourage people to experiment
  on -testnet with new features, or they will figure out less efficient
  ways of wedging what they want to do into the existing standard
  transaction types. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0819}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 19:12:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6189.msg90712@s{hash}msg90712
@section 3 {tx}

  @p{««}Linux and Windows binary releases are at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Changes and new features include: @p{»»}

    @p{(li}Support for Universal Plug and Play to open a port for incoming
    connections (off by default, turn it on using the -upnp=1 command-line
    switch or the checkbox on the Options dialog box).@p{li)}

    @p{(li}Sending and displaying arbitrary precision amounts of bitcoins
    (you can send exactly 1.0001 bitcoins if you like). Sending less than
    0.01 bitcoins requires a 0.01 bitcoin fee, however.@p{li)}

    @p{(li}New rpc command "sendmany" to send bitcoins to more than one
    person in a single transaction (already being used by some of the
    mining pools for payouts).@p{li)}

    @p{(li}Several bug fixes, including a serious intermittent bug that
    would sometimes cause bitcoind to stop accepting rpc requests.@p{li)}

  @p{««}If you find bugs, report them at: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0820}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 19:30:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5813.msg90731@s{hash}msg90731
@section 3 {tx}

  @s{quotedtext}

  @p{««} After putting together the 0.3.21 release candidate today, I'm
  thinking after 0.3.21 is out the door it might be a good time to do a
  major source tree re-org. I like the idea of following the GNU directory
  layout standard, and it would make my job easier if source was in src/,
  readmes/etc were in doc/, scripts to automate the Windows build were in
  build/, etc. @p{»»}

  @p{««}PS: jaromil is the second person I've heard who says they'd prefer
  a development mailing list. I don't care one way or another, but it
  would be easy to create one using SourceForge's mailing list feature.
  What do others think?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0821}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 19:37:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5943.msg90736@s{hash}msg90736
@section 3 {tx}

  @s{quotedtext}

  @p{««}Actually, Clearcoin only requires 3 confirmations. @p{»»}

  @p{««}And now that I've got some pressing core bitcoin stuff off my
  plate, I'll get back to working on a -testnet version of Clearcoin, and
  as soon as that is done I'll be announcing a JSON-RPC API so you can
  write code that interacts with clearcoin (creating escrows, getting
  their status, releasing coins if you're properly authorized, etc). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0822}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 20:01:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5171.msg90761@s{hash}msg90761
@section 3 {tx}

  @p{««}We've already got ParseMoney in util.cpp, this patch adds
  parseNumber/uriParseAmount. Having more than one way to convert strings
  into bitcoin amounts is not a good idea, in my humble opinion. @p{»»}

  @p{««}Also, instead of having a separate executable it would be more
  'wxbitcoin-like' to have one executable that acts as either client or
  server depending on what command-line arguments are given. The problem
  with two executables is you'll have clueless users double-clicking on
  bitcoinuri.exe and then wondering why it doesn't do anything. @p{»»}

  @p{««}I do like the use of boost message queues to communicate. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0823}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-20 21:39:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6189.msg90852@s{hash}msg90852
@section 3 {tx}

  @p{««}RE: changing the confusing transaction fee message: good idea, and
  yes, "we" can. @p{»»}

  @p{««}How about: @p{»»}

  @p{««}This transaction requires a transaction fee of at least 0.0N
  because of its amount, complexity, or use of recently received funds
  @p{»»}

  @p{««} I don't want to use the word "recommend", because the GUI doesn't
  let you try to send them without a fee. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0824}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-21 01:29:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6150.msg90997@s{hash}msg90997
@section 3 {tx}

  @p{««}18-21 August works for me. New York City in August: ah, I can smell
  it now.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0825}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-21 19:35:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6159.msg91702@s{hash}msg91702
@section 3 {tx}

  @s{quotedtext}

  @p{««}Because there is a real cost to the network for every transaction,
  and the code hasn't been fully optimized yet. @p{»»}

  @p{««}Allowing users and miners to set fee policy without recompiling
  will happen, but I think there are higher priority issues to tackle
  first.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0826}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-22 00:37:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6206.msg91904@s{hash}msg91904
@section 3 {tx}

  @s{quotedtext}

    @p{(li}@p{(li}1 @p{li)}

  @p{««}Y'all have heard of the KISS principle, right?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0827}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-22 14:54:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6172.msg92177@s{hash}msg92177
@section 3 {tx}

  @s{quotedtext}

  @p{««} Very good idea. Anybody want to implement it? I've got a Python
  tool that walks the block chain gathering transaction statistics: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Teaching it to compute 'bitcoindays destroyed' shouldn't be
  terribly hard. I think. @p{»»}

  @p{««}This morning I taught it to add just the smallest or just the
  largest output in each TxOut and report the range to get an estimate of
  'true' transaction value being exchanged without counting change TxOuts
  or mining pool payouts. @p{»»}

  @p{««}So, to be conservative, assume that the biggest-value TxOut for
  every transaction is change and the smallest is the actual bitcoins
  being transferred. Taking the smallest TxOut of all the transactions
  last month, an average of about 35,000 BTC were sent per day. @p{»»}

  @p{««}This month the average is about 55,000 BTC per day. Add in the
  MtGox trading volume to get a reasonable lower estimate of something
  like 70-80,000 BTC changing hands every day. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0828}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-22 15:50:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6284.msg92201@s{hash}msg92201
@section 3 {tx}

  @s{quotedtext}

  @p{««} Today, it costs the entire network something like @p{(link}$0.001
  to process each transaction@p{link)}. @p{»»}

  @p{««}The limiting factor is checking to see if the transaction is valid
  or not (the CPU cost of ECDSA signature verification). When the
  transaction volume gets high enough miners will have to start
  prioritizing which transactions they check, and they will use
  transaction fees as a quick initial check to see if they should invest
  CPU cycles to include transactions in a block. Yes, miners want to
  include as many transactions with fees as possible in their blocks, but
  it won't be economical for any miner or mining pool operator to include
  an infinite number of them. @p{»»}

  @p{««}And speaking of mining pools... they are a lot more efficient than
  individual miners because they allow transactions to be verified once
  instead of requiring that all of the miners in the pool do that work.
  Very small miners will be driven to join a mining pool, and the big
  mining pools will be competing to have the lowest fees and highest
  payouts (and so will be optimizing their ECDSA verification code and
  will figure out which transactions are profitable and which aren't).
  @p{»»}

  @p{««}So: I don't think bitcoin will have very few miners. I think it
  will have lots of miners connected to a smaller number of mining pools,
  and the whole system will optimize itself to be wonderfully efficient.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0829}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-22 16:18:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6017.msg92220@s{hash}msg92220
@section 3 {tx}

  @p{««}My turn to be the newbie: Is there a high-level discussion of the
  economics of NameCoin or DNS in general somewhere? What is the scare
  resource that needs to have a price attached? @p{»»}

  @p{««}My half-baked thoughts: @p{»»}

  @p{««}Seems like domain names are not the scarce resource; CPU power
  available to process transactions is the scarce resource. So it seems to
  me simply not allowing any free transactions, allowing an arbitrary
  number of "new domain" and "domain transfer" transactions with arbitrary
  fees attached, and allowing the mining nodes to decide which
  transactions to accept into their blocks and which to drop will create
  the "right" number of domain names at the "right" price. @p{»»}

  @p{««}Any individual, well-known domain name @p{(it}is@p{it)} a scarce
  resource. "google.namecoin" is worth more than
  "xblkje4klj21.namecoin"... but if I want to get the google.namecoin
  domain name from google (or a domain squatter), and google or the domain
  squatter is willing to keep paying the (minimal) NameCoin renewal
  transaction fee, then I can just offer them cash or bitcoins (or
  NameCoins) to transfer the domain to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0830}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-23 03:02:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6322.msg92753@s{hash}msg92753
@section 3 {tx}

  @s{quotedtext}

  @p{««}I am mostly a pacifist.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0831}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-23 03:15:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5953.msg92760@s{hash}msg92760
@section 3 {tx}

  @p{««}All that Icelandic geothermal power could make them a mining hot
  spot, too.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0832}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-23 22:27:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6085.msg93330@s{hash}msg93330
@section 3 {tx}

  @p{««}Governments can print money, so if they want bitcoins it would be
  much more efficient for them to just buy them (with newly printed money)
  than try to mine them. @p{»»}

  @p{««}Going on a bit of a tangent: @p{»»}

  @p{««}Once common criticism of bitcoin is that there is nobody like the
  Federal Reserve to "smooth out the bumps in the economy by manipulating
  the money supply." Set aside for a minute whether or not the Fed
  actually does a good job of that or whether or not the Fed actually has
  the ability to do that. @p{»»}

  @p{««}One response is that there is absolutely nothing stopping the
  Federal Reserve, or anybody else, from stepping in and "smoothing out
  the bumps in the bitcoin economy." The Fed could buy bitcoins when it
  thought the value was too low, and sell them when it thought the value
  was too high. It'd have to plan ahead and keep a big stock on hand so it
  had some to sell, of course. @p{»»}

  @p{««}That might lead to a productive discussion on why that would or
  wouldn't work, and if or how it is different from what the Fed (or the
  World Bank) does now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0833}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-23 23:52:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6393.msg93432@s{hash}msg93432
@section 3 {tx}

  @p{««}I thought I'd explain a little more why I think most conservatives
  might have a negative reaction to bitcoin, why libertarians love it, and
  why I think liberals might be convinced to love it. @p{»»}

  @p{««}I'm starting from Jonathan Haidt's @p{(link}Moral Foundation
  Theory@p{link)}, which says that we all have five basic universal moral
  foundations: @p{»»}

    @p{(li}Harm/care@p{li)}

    @p{(li}Fairness/reciprocity@p{li)}

    @p{(li}Ingroup/loyalty@p{li)}

    @p{(li}Authority/respect@p{li)}

    @p{(li}Purity/sanctity@p{li)} Different cultures and people of
  different political or religious viewpoints feel more strongly about
  some of these than others. Conservatives score pretty highly on all
  five; liberals score very high on the first two. Libertarians...
  @p{(link}are complicated@p{link)}. More like conservatives when it comes
  to money, more like liberals when it comes to social issues. @p{»»}

  @p{««}So: how do I think people will react to bitcoin for each of the
  five moral foundations? @p{»»}

  @p{««}Harm/care: if Bitcoin gets a reputation for 'that online currency
  that the criminals and drug dealers use' then that's bad. @p{»»}

  @p{««}Fairness/reciprocity: if Bitcoin is seen as 'that online currency
  that made a bunch of early adopter geeks obscenely wealthy' then that's
  bad. @p{»»}

  @p{««}Ingroup/loyalty: I think conservatives might feel like bitcoin is
  an affront to Their National Currency (whatever currency that happens to
  be). @p{»»}

  @p{««}Authority/respect: Conservatives probably won't like a rag-tag band
  of open source rebels trying to overthrow The Authorities. I'm not happy
  about the tone of the recent Forbes article, for example. @p{»»}

  @p{««}Purity/sanctity: Assuming we can get past the Harm/care problems, I
  actually think bitcoin could be positioned as the purest form of online
  money. @p{»»}

  @p{««}Moral Foundations Theory strikes me as probably right (and it's
  backed by pretty solid research, it is not just philosophical musings).
  I've been thinking about how to "frame" bitcoin to appeal to people on a
  moral/emotional level. Random thoughts: @p{»»}

  @p{««}Fairness/reciprocity: if you're an early adopter geek, start
  circulating your coins@p{--} send them to MyBitcoin or MtGox and then
  back to yourself if you want to keep them, but make it hard to tell if
  there ARE any early adopter geeks holding lots of coins. And if you're
  talking about bitcoin, compare it to the fairness of the current system,
  where bankers are allowed to create (and profit from) creation of money.
  @p{»»}

  @p{««}What do y'all think? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0834}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-24 23:20:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6430.msg94290@s{hash}msg94290
@section 3 {tx}

  @p{««}What's the extra CPU cost for recovering the public key? Current
  bottleneck for bitcoin transaction processing is the CPU cost of ECDSA
  signature verification, not disk space or bandwidth, so saving bytes at
  the expense of more CPU is not the right thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0835}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-24 23:40:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2926.msg94312@s{hash}msg94312
@section 3 {tx}

  @s{quotedtext}

  @p{««} I dunno, you tell me@p{--} the idea is anybody can use
  gitian-builder to create trusted releases, right? Working with BlueMatt
  to make the nightlies use it seems like the right place to start. @p{»»}

  @p{««}Mucking with the Linux build process isn't high on my own personal
  TODO list, I have my hands busy wrestling with the Windows build (can
  gitian build windows mingw bitcoin binaries?) and setup.nsi... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0836}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-24 23:45:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6424.msg94318@s{hash}msg94318
@section 3 {tx}

  @s{quotedtext}

  @p{««} That really aught to be openssl .. &amp;&amp; rm -f ... @p{brk}
  ... or maybe something more complicated to make sure the wallet
  encryption/writing completed OK before removing the wallet.dat. Like
  checking to make sure wallet.dat.aes256's filesize doesn't get smaller
  through the decrypt...use...re-encrypt cycle. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0837}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 00:28:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6366.msg94344@s{hash}msg94344
@section 3 {tx}

  @p{««}If I were Satoshi... I would have built a modest amount of
  inflation in to bitcoin. "Modest inflation is what most people are
  comfortable and familiar with," I would have reasoned to myself, "so
  that's the right thing to do." @p{»»}

  @p{««}However... I'm not so sure that would have worked. It is
  @p{(it}very@p{it)} nice to be able to say "bitcoins are valuable because
  they are rare, and they are rare because they are designed that
  way@p{--} there will never be more than 21-million of them." That is
  easy to understand, and gives bitcoins a clear advantage over existing
  currencies. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0838}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 00:35:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5914.msg94350@s{hash}msg94350
@section 3 {tx}

  @p{««}The testnet Faucet has 7,000 testnet coins in it, you can get 50 at
   a time at: @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0839}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 12:28:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6284.msg94832@s{hash}msg94832
@section 3 {tx}

  @p{««}You are forgetting that there are (at least) three players in the
  bitcoin economy: miners, users... and merchants. @p{»»}

  @p{««}If transaction fees are driven to zero so miners start dropping
  out, then merchants have an incentive to step in and start mining
  themselves so their transactions get processed in a timely manner.
  Otherwise they don't get paid. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0840}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 12:53:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6388.msg94839@s{hash}msg94839
@section 3 {tx}

  @p{««}Best thing I've bought: Boston Red Sox tickets (from a friend who
  has season tickets). @p{brk} Second best: my alpaca socks. @p{brk} And
  I've bought three or four lunches with bitcoins so far (also from
  friends@p{--} they pay, then I repay them in BTC). @p{»»}

  @p{««}I really wish I had a use for Golden Mean Calipers, they look
  nifty.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0841}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 14:40:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6496.msg94916@s{hash}msg94916
@section 3 {tx}

  @p{««}I've deployed a -testnet version of ClearCoin, at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}It is fully functional, so feel free to creates some escrow
  transactions and get some testnet bitcoins from the the testnet faucet
  (which I will eventually move to testnet.freebitcoins.appspost.com).
  @p{»»}

  @p{««}For anybody else developing on App Engine, here's what I did to
  make it work: @p{»»}

  @p{««}In my main.py: @p{»»}

  @s{code}

    @p{(li}if 'test' in os.environ('CURRENT_VERSION_ID'): @p{li)}

    @p{(li} set_namespace('testnet') @p{li)}

  @p{««}CURRENT_VERSION_ID is the version of your app that's running, and
  is set by App Engine. @p{brk} set_namespace makes all subsequent
  datastore and memcache operations read/write from a different database.
  So almost all of the code for ClearCoin doesn't care whether it is
  handling testnet coins, it just works. @p{»»}

  @p{««}The only other change needed was a check for 'test' in
  os.environ('CURRENT_VERSION_ID') when deciding which bitcoind server to
  use. I run the -testnet bitcoind for ClearCoin on a different machine
  than the production bitcoind, so experiments on the test net won't
  affect the production ClearCoin at all. @p{»»}

  @p{««}If you're not running on App Engine, you should think about
  building in the equivalent of CURRENT_VERSION_ID and 'set_namespace' so
  deploying test and production versions of your application is easy.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0842}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 17:50:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6460.msg95076@s{hash}msg95076
@section 3 {tx}

  @p{««}RE: other weird variable type requirments: @p{brk} sendmany's
  second argument is a JSON Object, with string keys and number (float)
  values. I think the equivalent in PHP is a PHP Array (indexed by
  string). @p{»»}

  @p{««}Several routines take @p{(link}boolean@p{link)} arguments. @p{brk}
  All the rest are strings or numbers. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0843}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 23:04:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6503.msg95387@s{hash}msg95387
@section 3 {tx}

  @p{««}To steal your bitcoins by breaking crypto (as opposed to getting
  your private key), somebody would have to: @p{»»}

    @p{(li} 1. Break RIPEMD160. Because your bitcoin address is a
    RIPEMD160 hash... AND @p{li)}

  2. Break SHA256. Because your bitcoin address is a RIPEMD160 hash of the
  SHA256 hash... AND @p{li)}

  3. Break the ECDSA elliptic curve @p{(so}encryption@p{so)} signature
  algorithm, to figure out the private key that corresponds to the public
  key that they got from breaking (1) and (2). @p{li)}

  @p{««}That's assuming that you don't re-use bitcoin receiving addresses
  (your public key is revealed the first time you spend coins that were
  sent to that address). If you do re-use the same receiving address, then
  they just need (3). @p{»»}

  @p{««}I don't spend any time worrying about whether or not the NSA (or
  anybody else) can break ECDSA. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0844}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 23:28:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6428.msg95410@s{hash}msg95410
@section 3 {tx}

  @s{quotedtext}

  @p{««} So: the danger isn't revealing private keys (I mis-remembered),
  the danger is a naive developer will see the signmessage RPC command,
  not realize that signing arbitrary data can be dangerous, and put up a
  web page that lets somebody enter arbitrary data to be signed with one
  of the developer's public keys. @p{»»}

  @p{««}This might just be a documentation issue, although if signmessage
  was changed to sign a hash of the passed-in message instead of the
  message itself then it would be completely safe.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0845}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-25 23:34:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6511.msg95419@s{hash}msg95419
@section 3 {tx}

  @s{quotedtext}

  @p{««}What operating system? This sounds like a wxWidgets or bitcoin
  client bug that needs fixing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0846}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-27 17:29:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6642.msg97074@s{hash}msg97074
@section 3 {tx}

  @p{««}Binaries for Bitcoin version 0.3.21 are available at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Changes and new features from the 0.3.20 release include: @p{»»}

  @p{(li}* Universal Plug and Play support. Enable automatic opening of a
  port for incoming connections by running bitcoin or bitcoind with the 
  @s{code} command line switch or using the Options dialog box. @p{li)}

  @p{(li}* Support for full-precision bitcoin amounts. You can now send, and
  @p{brk} bitcoin will display, bitcoin amounts smaller than 0.01.
  However, @p{brk} sending fewer than 0.01 bitcoins still requires a 0.01
  bitcoin fee (so @p{brk} you can send 1.0001 bitcoins without a fee, but
  you will be asked to @p{brk} pay a fee if you try to send 0.0001). @p{li)}

  @p{(li}* A new method of finding bitcoin nodes to connect with, via DNS A
  @p{brk} records. Use the -dnsseed option to enable. @p{li)}

  @p{««}For developers, changes to bitcoin's remote-procedure-call API:
  @p{»»}

  @p{(li}* New rpc command "sendmany" to send bitcoins to more than one
  address @p{brk} in a single transaction. @p{li)}

  @p{(li}* Several bug fixes, including a serious intermittent bug that
  would @p{brk} sometimes cause bitcoind to stop accepting rpc requests.
  @p{li)}

  @p{(li}* -logtimestamps option, to add a timestamp to each line in
  debug.log. @p{li)}

  @p{(li}* Immature blocks (newly generated, under 120 confirmations) are
  now @p{brk} shown in listtransactions. @p{li)}

  @p{««} SHA1-checksums for the binary files are: @p{»»}

  @p{««}@s{code} (mac version should be ready soon) @p{»»}

  @p{««}Thanks to all those who contributed to this release: @p{»»}

  @p{««}Dan Helfman @p{brk} Dan Loewenherz @p{brk} devrandom @p{brk} Eric
  Swanson @p{brk} gjs278 @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk}
  Matt Corallo @p{brk} Matt Giuca @p{brk} Nils Schneider @p{brk} ojab
  @p{brk} Pieter Wuille @p{brk} sandos @p{brk} Santiago M. Mola @p{brk}
  Sven Slootweg @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0847}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-27 19:00:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg97181@s{hash}msg97181
@section 3 {tx}

  @p{««}I want to get this out in the open because it is the kind of thing
  that will generate conspiracy theories: I'm going to give a presentation
  about Bitcoin at CIA headquarters in June at an emerging technologies
  conference for the US intelligence community. @p{»»}

  @p{««}I accepted the invitation to speak because the fact that I was
  invited means Bitcoin is already on their radar, and I think it might be
  a good chance to talk about why I think Bitcoin will make the world a
  better place. I think the goals of this project are to create a better
  currency, create a more competitive and efficient international payment
  system, and give people more direct control over their finances. And I
  don't think any of those goals are incompatible with the goals of
  government. @p{»»}

  @p{««}I'm only very slightly worried that talking about bitcoin at the
  CIA will increase the chances they'll try to do something we don't want
  them to do. I think accepting their invitation and being open about
  exactly what bitcoin is will make it less likely they'll see it as a
  threat. @p{»»}

  @p{««}PS: Full disclosure: I'll be paid a one-time fee of $3,000 to cover
  expenses and pay me for my time. I don't want any "Gavin is on the CIA's
  payroll" rumors to get started, either... @p{»»}

  @p{««}As always, comments and questions and discussion welcome. I'd
  really rather not hear any conspiracy theories about how they'll
  secretly implant a mind-control chip in my head while I'm there,
  though.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0848}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-27 19:01:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6642.msg97183@s{hash}msg97183
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yup. I think this might be the last release I do that, though...
  @p{»»}

  @p{««}EDIT: Done, svn revision 251. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0849}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 15:13:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg98130@s{hash}msg98130
@section 3 {tx}

  @p{««}Wow, I new this would generate discussion... but wow! @p{»»}

  @p{««}A couple of quick notes: @p{»»}

  @p{««}noagenda nailed it@p{--} I was contacted specifically by In-Q-Tel,
  the CIA's "look for interesting/promising new private technologies and
  then invest in them" spin-off. I get the impression they organize the
  conference. This year the conference is about money. @p{»»}

  @p{««}They are serious about security; there will be no recording, and I
  will not be allowed to bring any electronic devices with me. I am
  planning on posting my talk, and if I get my act together in time I'll
  try to post it before I give it so y'all can give me feedback. @p{»»}

  @p{««}I'll be signing an agreement that I, or my company, will not use my
  appearance for publicity purposes. So please, no unofficial "from the
  bitcoin community" press releases about this. @p{»»}

  @p{««}If talking to them makes y'all trust me less... then good! I'd like
  to see more careful code review, and, as others have pointed out, if
  bitcoin can be destroyed by one person, or requires the leadership of
  one person, then it has failed to be the strong, decentralized system
  that I think it is. @p{»»}

  @p{««}RE: me == satoshi: here's some C++ code I wrote 15 years ago: @p{»»}

    @p{(li}@s{(link)} @p{li)} I have a very different coding style from
  Mr. Nakamoto. And I don't know nearly enough crypto to build something
  like bitcoin by myself. @p{»»}

  @p{««}And one final note: the US government is a really, really, really
  big organization. Like any big organization, different parts have
  different motives and goals. I hope I'll get a little tiny glimpse into
  what one part of that big organization thinks about bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0850}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 15:29:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6642.msg98158@s{hash}msg98158
@section 3 {tx}

  @p{««}RE: Mac builds: what BlueMatt said. Despite using a Mac as my
  development machine, I am not a Mac developer@p{--} I'm an old Unix
  developer at heart. I learned enough Windows "Win32-api" programming to
  create a couple of products, and I know a lot about web development, but
  I'm a newbie when it comes to making applications for the Mac. @p{»»}

  @p{««}RE: wallet encryption: I want encryption of wallet private keys
  (requiring you to enter your password to send coins) to be part of the
  next release, and I think that is a big enough feature to bump the next
  release version to "0.4". @p{»»}

  @p{««}RE: x86-64 client: for the Windows? or for Linux? 32-bit should
  work find on 64-bit Windows, there's no real reason to do a 64-bit
  version. For Linux, there should be a bitcoin in bin/64/ @p{»»}

  @p{««}RE: bitcoind not forking by default any more: yes, that is
  intentional, and I forgot to mention it in the release notes. When the
  mac binary is done I'll update the README. Run bitcoind -daemon (or put
  daemon=1 in the bitcoin.conf file) and you'll get the old behavior.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0851}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 15:35:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg98168@s{hash}msg98168
@section 3 {tx}

  @s{quotedtext}

  @p{««}Me and my good friend Charlie will spend it on hookers and blow, of
  course. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0852}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 16:39:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg98266@s{hash}msg98266
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yep, I live in Amherst, Massachusetts; my family moved to the US
  when I was 5 years old. @p{»»}

  @p{««}I will be visiting Australia (Sydney for a couple of days then
  Tasmania for a couple weeks then Cairns for a week or two) in July.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0853}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 20:02:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6733.msg98541@s{hash}msg98541
@section 3 {tx}

  @p{««}We got a request a couple days ago for somebody to do an interview
  with a Brazilian radio station about bitcoin. @p{»»}

  @p{««}Any volunteers? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0854}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-28 23:08:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6744.msg98696@s{hash}msg98696
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think there's a good chance (mmm... 65.3%) that within 4 years
  one or more of the largest 1,000 US banks will support currency exchange
  to/from bitcoin for their customers. @p{»»}

  @p{««}Why would bitcoin be a threat to banks? They're really good at
  securely handling currency; that's a valuable service, whether the
  currency is dollars or euros or bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0855}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-29 13:59:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6781.msg99368@s{hash}msg99368
@section 3 {tx}

  @p{««}0.001 BTC at today's exchange rate is uncomfortably close to the
  @p{(link}estimated network-wide cost@p{link)} of processing a bitcoin
  transaction (which is about 0.001 US dollars). @p{»»}

  @p{««}The danger is a flood of micro-transactions that keep everybody's
  CPUs busy, driving up that hidden cost and, eventually driving people to
  stop running bitcoin because the costs aren't worth the benefits. @p{»»}

  @p{««} Also: lets not confuse the "how many free transactions" with "what
  is the smallest transaction amount you can send." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0856}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-29 16:57:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6642.msg99523@s{hash}msg99523
@section 3 {tx}

  @s{quotedtext}

  @p{««} You're running into the "very low priority transactions require a
  fee" rule. Priority depends on the value of the transaction (fewer
  bitcoins == lower priority) and how long ago you received the bitcoin(s)
  (older == higher priority). @p{»»}

  @p{««}That rule was in place for 0.3.20.2, but only for most miners. Most
  would not include very-low-priority transaction in blocks until they
  were old enough to have a high priority. The result was a big backlog of
  very-small transactions starting to build up. @p{»»}

  @p{««}With 0.3.21, the rules are the same for miners, for relaying
  transactions across the network, and for the user interface@p{--} if
  your transaction is very-low-priority, it won't get relayed and the user
  interface will insist that you pay a fee if you really want it
  transmitted RIGHT NOW. @p{»»}

  @p{««}If you really really really need to send 0.01 bitcoins right now,
  then you'll have to pay the fee. If you're willing to wait a while,
  you'll find you can send it without a fee after it is old enough and has
  enough priority. @p{»»}

  @p{««}All of this is to discourage people from "penny flooding" @p{--}
  constantly sending pennies back and forth to themselves without a fee
  just because they can. @p{»»}

  @p{««}Footnote: if you don't upgrade, you can send that 0.01 bitcoins
  without a fee. But as everybody else upgrades, you'll find that it will
  take a long time for that transaction to get confirmed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0857}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-29 17:05:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6785.msg99536@s{hash}msg99536
@section 3 {tx}

  @p{««}Fantastic idea! @p{»»}

  @p{««}My only suggestion would be a "copy to clipboard" icon/link next to
  the funding address (I need to do that for ClearCoin, too@p{--} haven't
  looked into how to do it yet, but github does it so I know it can be
  done...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0858}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-30 02:26:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6744.msg100032@s{hash}msg100032
@section 3 {tx}

  @s{quotedtext}

  @p{««} But they won't have the experience jumping through all the banking
  system regulatory hoops, or experience dealing with currencies other
  than bitcoin. @p{»»}

  @p{««}I expect lots of successful bitcoin vault services, and I expect
  one or more of them to be purchased by one or more banks and made a part
  of the banks' money services business. If they see bitcoin vault
  services making big profits, they'll want to own one. @p{»»}

  @p{««}My predictions are frequently wrong, though. Maybe US banks will
  fight bitcoin tooth-and-nail, or maybe the legal issues will be too
  unclear for any bank to risk getting involved. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0859}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-30 22:58:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6785.msg101094@s{hash}msg101094
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is definitely an issue@p{--} the account code doesn't keep
  track of where the coins it is sending out came from, so if you accept
  0-confirmation coins you're vulnerable to double-spending attacks (see,
  for example, the discussion of the "Finney attack" in these forums).
  @p{»»}

  @p{««}Seeing coins show up right away is a fantastic feature, though, so
  I'd suggest getting the 0-confirmation balance and a 3+-confirmation
  balance, allowing only 3+ confirmed coins to be withdrawn, and
  displaying the difference as 'waiting confirmation'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0860}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-30 23:11:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6856.msg101125@s{hash}msg101125
@section 3 {tx}

  @p{««}Uhhh... maybe a specific example will help. Lets say you start with
  accounts/balances of: @p{»»}

  @p{««}A: 5 @p{li)}

  B: 5 @p{li)}

  "": 1 @p{brk} Total wallet balance: 11 @p{»»}

  @p{««}Now you send 5 BTC from A, and pay a 0.01BTC fee. Account balances
  will be: @p{»»}

  @p{««}A: -0.01 BTC @p{li)}

  B: 5 @p{li)}

  "": 1 @p{brk} Total wallet balance: 5.99 @p{»»}

  @p{««}The fee isn't 'taken' from either B or "". You'll have to decide
  how to handle fees; for ClearCoin, I keep a positive balance in the ""
  account and automatically move coins from there if a transaction results
  in a fee (so for the above case, 0.01 bitcoins would be moved from the
  "" account to A, so A ended up with a zero balance and the fee is paid
  from ""). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0861}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-04-30 23:14:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6298.msg101128@s{hash}msg101128
@section 3 {tx}

  @s{quotedtext}

  @p{««} The built-in coin selection algorithm already prefers using older
  coins rather than newer ones.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0862}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-01 00:22:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4793.msg101213@s{hash}msg101213
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nothing against jav, but I think instawallet needs a month or
  three of 'soak time' to give the scammers and script kiddies time to try
  to break it (and to see how jav reacts to the scammers and script
  kiddies trying to break it...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0863}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-01 14:14:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6946.msg102074@s{hash}msg102074
@section 3 {tx}

  @p{««}tail -f ~/.bitcoin/debug.log @p{brk} ... will show you what
  bitcoind is doing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0864}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-01 17:55:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6856.msg102284@s{hash}msg102284
@section 3 {tx}

  @p{««}"you didn't offer a fee" is misleading; the bitcoin software 99+%
  of people are using today doesn't let "you" very much flexibility in how
  you offer fees. So basically, 99+% of people using bitcoin are charged
  fees based on a set of built-in rules. @p{»»}

  @p{««}If you want to send a fee with every transaction, you can run
  bitcoin with the -paytxfee= option; there isn't much reason to do that
  now, unless you're generating lots of very small (few-bitpenny)
  transactions. The Bitcoin Faucet is running with -paytxfee=0.01 because
  it DOES generate lots of very small transactions. @p{»»}

  @p{««}From the wiki: @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms0865}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-02 17:47:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7068.msg103407@s{hash}msg103407
@section 3 {tx}

  @p{««}I launched a new version of the Bitcoin Faucet today, with a few
  changes: @p{»»}

    @p{(li} 1. Payout is now 0.02 bitcoins (down from 0.05), to reflect
    the rise in value of bitcoins versus other currencies. @p{li)}

    @p{(li} 2. @p{(link}Recent Sends@p{link)} page, showing scrambled
    email addresses and (not scrambled) IP addresses of the last 100
    people to get coins from the Faucet. @p{li)}

    @p{(li} 3. Behind the scenes, faucet payouts are bundled up and sent
    in batches every N minutes, to minimize the fees that the Faucet pays.
    @p{li)}

  @p{««}I want to recruit some trusted volunteers to be "Faucet Police"
  @p{--} if somebody notices a fishy pattern of either IP addresses or
  email addresses, I'll give the Faucet Police the ability to temporarily
  stop the flow of coins from the Faucet. @p{»»}

  @p{««}If you're willing to help out and you've got a good
  reputation/history here on the forums, email me
  (@p{(link}gavinandresen@s{at}gmail.com@p{link)}) your google account
  information along with what time zone you're usually in, and I'll try to
  pick a couple handfuls of people so no matter what time of day or night,
  somebody will be awake and ready to turn off the spigot. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0866}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-03 12:54:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7123.msg104499@s{hash}msg104499
@section 3 {tx}

  @s{quotedtext}

  @p{««} All command-line options (except for -datadir and -conf) can be
  specified in the config file. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0867}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-03 23:12:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7166.msg105223@s{hash}msg105223
@section 3 {tx}

  @p{««}Neat idea! @p{»»}

  @p{««}I don't like the economics of it, though. @p{»»}

  @p{««}First, it reinforces the "if you started mining early you are rich
  only because you were lucky enough to be early" idea. And a lot of
  people already think that is unfair; give the early miners a current
  mining discount and you're just "helping the rich get richer." @p{»»}

  @p{««}Second, what stops an attacker from offering early miners $$$ for
  their (already spent) coinbase private keys? If they have value because
  they give a mining discount, then there WILL be a market for them. A
  wealthy attacker could just buy up as many as they can find and then
  take over the network with less hashing power... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0868}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-03 23:37:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6428.msg105247@s{hash}msg105247
@section 3 {tx}

  @s{quotedtext}

  @p{««}You're suggesting: @p{brk}
  ECDSA_SIGN(SHA256(RIPEMD160(SHA256(public_key))+"fixed string"+message))
  @p{brk} is more secure than: @p{brk} ECDSA_SIGN(SHA256("fixed
  string"+message)) @p{»»}

  @p{««}It sure looks more secure! But maybe some super-smart cryptographer
  will tease out a relationship between all the hashing and signing in the
  first version and it will turn out to be less secure; maybe she'll
  figure out a way to factor out the private key if the public key is
  involved in the salt. @p{»»}

  @p{««}I like the simpler version better. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0869}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-03 23:52:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5965.msg105258@s{hash}msg105258
@section 3 {tx}

  @p{««}RE: agreed upon spot to place or distribute messages: @p{»»}

  @p{««}I think it is time to start experimenting with a @p{lt}bytes@s{gt}
  OP_DROP OP_DUP OP_HASH160 ...etc transaction type on the testnet. @p{»»}

  @p{««}And time to finish implementing headers-only-for-initial-download
  mode so new users don't have to wait so long to get their free Faucet
  bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0870}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-04 00:07:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6825.msg105271@s{hash}msg105271
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bitcoin 0.3.21 puts a 'bestblock' entry in the wallet so it will
  automatically -rescan if you restore an old wallet (and it only rescans
  the blocks necessary to get up-to-date). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0871}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-04 04:03:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7172.msg105479@s{hash}msg105479
@section 3 {tx}

  @p{««}bitcoind doesn't prompt before adding fees because it is meant to
  be used by websites and other services where there may not be a person
  available to push an "Ok, pay a fee" button. There might not even be a
  place to put the button, either. @p{»»}

  @p{««}Your Transaction 2 paid a fee because it ran into the "small,
  low-priority transactions must pay" code that is new with version
  0.3.21. It was low priority because its outputs were small and its input
  was fairly new. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0872}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-04 12:41:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7195.msg105862@s{hash}msg105862
@section 3 {tx}

  @s{quotedtext}

  @p{««} The latest version of bitcoin @p{(bf}does@p{bf)} try to avoid
  "sub-cent change" by adding more inputs. @p{»»}

  @p{««}If it can't avoid it (e.g. you have 32.29 in your wallet and you
  send 32.28999999), then the sub-cent change becomes a sub-cent
  transaction fee. It isn't lost, the miner that includes the transaction
  will get it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0873}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-04 17:39:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7221.msg106119@s{hash}msg106119
@section 3 {tx}

  @p{««}I was actually thinking a return address would be a good use for
  the arbitrary-message-to-receiver OP_DROP transaction type. @p{»»}

  @p{««}Maybe make a convention that bytes be a JSON dictionary, so it
  could be: @p{»»}

  @p{««}@s{code} ...etc... @p{»»}

  @p{««}... which would be inefficient (58 bytes to encode the 20-byte
  return address) but wonderfully extensible. @p{»»}

  @p{««}And again: I'd like to see experimentation on testnet.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0874}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-04 20:25:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7247.msg106364@s{hash}msg106364
@section 3 {tx}

  @s{quotedtext}

  @p{««}So, team: anybody interested?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0875}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 11:59:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7205.msg107378@s{hash}msg107378
@section 3 {tx}

  @s{quotedtext}

  @p{««} +1 

# ----------------------------------------------------------------------
@section 2 {ms0876}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 12:15:27 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7305.msg107394@s{hash}msg107394
@section 3 {tx}

  @p{««}The project needs more bug fixing and testing, so I would rather
  NOT see bounties for new features. @p{»»}

  @p{««}Bounties for fixing bugs would be ok. And maybe a bug bounty, for
  finding significant bugs. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0877}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 14:03:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6899.msg107492@s{hash}msg107492
@section 3 {tx}

  @p{««}TED is about "the vision thing"; somebody really good at public
  speaking and putting together compelling presentations should do it.
  @p{»»}

  @p{««}Somebody who actually @p{(bf}enjoys@p{bf)} travelling around and
  speaking about something they are passionate about. I want to spend my
  time building stuff, not talking about stuff. @p{»»}

  @p{««}PS: I think bitcoin needs another year of growth before it is
  TED-worthy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0878}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 14:28:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7253.msg107518@s{hash}msg107518
@section 3 {tx}

  @p{««}@p{(link}Block 70136@p{link)} has 0.03BTC in un-spendable
  transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0879}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 15:09:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7240.msg107580@s{hash}msg107580
@section 3 {tx}

  @p{««}Half-baked thoughts: @p{»»}

  @p{««}Broadcasting policies makes me nervous@p{--} it is too easy to lie,
  and there might be some advantage to lying. @p{»»}

  @p{««}Couldn't clients infer all the information they need to know about
  what transactions/fees are being accepted by miners by keeping track of
  transactions in the memory pool and looking at the last 10,000-or-so
  generated blocks?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0880}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 16:02:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7305.msg107640@s{hash}msg107640
@section 3 {tx}

  @p{««}I'll brain-dump my second half-baked idea of the day: @p{»»}

  @p{««}github has a nice API for basically everything it does (issues
  getting closed,etc). @p{»»}

  @p{««}I've been working on an API for ClearCoin (creating escrow
  accounts, etc). @p{»»}

  @p{««}Marrying the two might work nicely. Coders could publish their
  bitcoin addresses in their github profiles. @p{»»}

  @p{««}Bounties could be established for bugs (or, grumble, features) by
  creating a ClearCoin account, linking it to the issue (maybe by posting
  a machine-readable comment via the github api). @p{»»}

  @p{««}And when the issue was closed via a commit the bounty could be
  automagically paid to the coder(s) who contributed to the commit.
  (somehow... via a yet-to-be-written way for ClearCoin to get a
  where-to-release-coins address that is not set in advance). @p{»»}

  @p{««}Reasons not to do it: allegations of corruption/favoritism if
  people doing the pulling have to decide between two pull requests. Maybe
  less cooperation to find/fix things if people are competing for
  bounties. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0881}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-05 21:18:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7325.msg108078@s{hash}msg108078
@section 3 {tx}

  @s{quotedtext}

  @p{««} +1 

# ----------------------------------------------------------------------
@section 2 {ms0882}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-06 13:32:21 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7410.msg108821@s{hash}msg108821
@section 3 {tx}

  @p{««}If you want each receiving address treated as its own account, you
  can: @p{brk} setaccount @p{lt}address@s{gt} @p{lt}address@s{gt} @p{brk}
  ... and then use @p{lt}address@s{gt} as the name of the account. @p{»»}

  @p{««}And validateaddress will tell you what account is associated with
  an address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0883}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-06 13:56:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7410.msg108842@s{hash}msg108842
@section 3 {tx}

  @p{««}No, the send-from address is not available, for a couple of
  reasons: @p{»»}

  @p{««}1) When people using a shared wallet service like MyBitcoin or
  MtGox send payments the "from address" could belong to any of the other
  users of the service (or could be a "change" address that doesn't belong
  to anybody). It is a bad idea to think that "address == person". @p{»»}

  @p{««}2) If more complicated transaction types are ever "turned on" in
  bitcoin, there might be more than one "from address". Satoshi
  designed-in support for complicated transactions like "this payment can
  only be spent if 2 of these 3 keys sign the transaction". In that case,
  there would be two "from addresses". @p{»»}

  @p{««}If you need this to refund coins, you'll need to ask the customer
  for a refund address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0884}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-06 15:36:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7421.msg108938@s{hash}msg108938
@section 3 {tx}

  @p{««}This has been lingering for months, and got bogged down in
  discussions of some nifty new mega-efficient binary protocol for stuff.
  That hasn't happened. So: @s{(link)} @p{»»}

  @p{««}This adds these new RPC commands: @p{»»}

  @p{««}monitortx/monitorblocks: POST JSON-RPC to a URL when new wallet
  transactions or blocks are received. @p{brk} listmonitored: list URLS
  that will be POSTed to @p{brk} getblock: get information about a block,
  given depth in main chain. @p{»»}

  @p{««}monitortx posts the same information you get from gettransaction.
  @p{brk} monitorblock/getblock posts: @p{»»}

  @s{code}


# ----------------------------------------------------------------------
@section 2 {ms0885}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-06 16:13:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7346.msg108967@s{hash}msg108967
@section 3 {tx}

  @s{quotedtext}

  @p{««} Priority is a function of how many bitcoins are involved in the
  transaction (more is higher priority), the size (in bytes) of the
  transaction (smaller is higher priority), and the age of the
  transaction's previous transactions (older is higher priority). @p{»»}

  @p{««}Your transaction is taking a long time because it involved only
  0.14 BTC which you got from a transaction that happened earlier today.
  If you were running bitcoin version 0.3.21, it would have required that
  you add a 0.01BTC fee to send it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0886}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-07 14:25:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7458.msg109984@s{hash}msg109984
@section 3 {tx}

  @p{««}If your 0.33 bitcoins came from one or two recent payments to you,
  then waiting a day or three to let the inputs "mature" will let you send
  them without a fee. The transaction priority fee rules are designed to
  discourage people from sending lots of small bitcoin transactions in a
  short time. @p{»»}

  @p{««}If your 0.33 bitcoins came from 20 or 30 penny-sized payments to
  you, then you'll have to go to a lot of work to send them without a fee,
  because a 20- or 30-input transaction will be too big to qualify to be
  free. The transaction size fee rules are designed to discourage people
  from wasting everybody's disk and network bandwidth by sending big
  transactions. @p{»»}

  @p{««}If you did receive lots of tiny payments, you can try to bundle
  them up in chunks@p{--} you might be able to send three payments of 0.10
  BTC without a fee (because each of them would be smaller than the "too
  big to be free" size). @p{»»}

  @p{««}But you should ask yourself: is it really worth your time? 0.01 BTC
  is less than 5 US cents. If it takes you more than 20 seconds to send 2
  or 3 payments to avoid the 0.01BTC fee, then you're valuing your time at
  less than US minimum wage. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0887}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-07 14:49:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7458.msg109996@s{hash}msg109996
@section 3 {tx}

  @s{quotedtext}

  @p{««} I learned long ago that it is much better to create a sub-optimal
  system that is simple and robust than to try to create a perfectly
  optimal system. @p{»»}

  @p{««}Pretty darn good, with the right incentives in place to drive the
  long-term desired behavior, is good enough for me right now. I think
  "we" have been pretty good at responding fairly quickly to problems as
  they appear. I'm keeping a close eye on the free-transaction backlog,
  but I think tcatm's recent changes to @s{(link)} , showing transaction
  priority, and the recent change to the bitcoin client, so the default
  fee rules are the same for miners, relaying across the network, and the
  client, are working nicely. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0888}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-07 17:48:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7458.msg110149@s{hash}msg110149
@section 3 {tx}

  @p{««}The rules that the GUI (and bitcoind sends) follows to figure out
  if you should pay a fee are now the same as the rules in the block
  generation code. The rules themselves didn't change. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0889}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-08 00:19:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7454.msg110494@s{hash}msg110494
@section 3 {tx}

  @p{««}The networking code is the same in either case, so it was almost
  certainly just a coincidence and you got unlucky with the peers you
  connected to running -server from the command line. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0890}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-08 12:25:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5587.msg111062@s{hash}msg111062
@section 3 {tx}

  @p{««}Wednesday May 25'th bitcoin lunch in la Defense is on my
  calendar.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0891}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 00:05:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7620.msg111876@s{hash}msg111876
@section 3 {tx}

  @s{quotedtext}

  @p{««} They tend to get put back together when you send larger payments.
  @p{»»}

  @p{««}The algorithm that the current bitcoin client uses isn't the best
  possible algorithm for deciding when to combine or split coins; ideally,
  it would have some notion of how big your average transaction would be,
  and when sending coins it might split change or combine extra coins to
  make change that is about that big (so the next time you make a
  transaction there are old, previous, high-priority transactions it can
  use). @p{»»}

  @p{««}If you ask nicely, I bet tcatm or somebody else will create a
  little web service that could tell you how long you have to wait for a
  0.10 (or whatever) coin to mature before you can send it without a fee.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0892}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 00:17:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6284.msg111893@s{hash}msg111893
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why? Thats years and years away. I don't think any of us can
  predict exactly what is going to happen 10 or 15 or 20 years from now; I
  don't think it is possible to get a consensus now because there has
  never been a system like bitcoin before, so predicting how merchants,
  miners, and users will interact in 10 years seems to me to be
  impossible. @p{»»}

  @p{««}So: do you think this supposed problem will happen all at once? Or
  will it happen slowly over time? If you think it will happen all at
  once, would there be any warning signs? If it is a problem that we can
  clearly see coming, then there will be time to react. @p{»»}

  @p{««}I'm much more worried on the problems I see coming in the next year
  or two or three@p{--} bitcoin-specific viruses and trojans, poorly coded
  bitcoin web services, and maybe bitcoin service operators getting
  charged with financial crimes that they didn't know they were violating.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0893}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 00:21:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7620.msg111899@s{hash}msg111899
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0894}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 01:32:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7638.msg111996@s{hash}msg111996
@section 3 {tx}

  @s{quotedtext}

  @p{««} No and no, in my opinion. @p{»»}

  @p{««}I think being able to explain the block reward as "starts at 50
  every 10 minutes and is cut in half every 4 years" is a big advantage. I
  like simple@p{--} "the simplest possible solution that will work" is a
  good engineering rule of thumb. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0895}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 15:21:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2022.msg112809@s{hash}msg112809
@section 3 {tx}

  @p{««}Will all of the internationalization/translations from the
  wxBitcoin port straight over to qtBitcoin? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0896}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 18:20:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7753.msg113041@s{hash}msg113041
@section 3 {tx}

  @p{««}Collusion to gain oversized-profits never succeeds in the
  long-term, unless there are artificial barriers to entry (like
  government regulations). @p{»»}

  @p{««}I won't worry until our governments decide to pass the Officially
  Licensed and Inspected Bitcoin Generating Devices Law. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0897}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 18:21:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7755.msg113044@s{hash}msg113044
@section 3 {tx}

  @p{««}No, it is not possible, there is a rule against that.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0898}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 18:35:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7749.msg113062@s{hash}msg113062
@section 3 {tx}

  @s{quotedtext}

  @p{««}Agreed; that is the longer-term goal. This is a short-term fix.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0899}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 19:01:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7755.msg113099@s{hash}msg113099
@section 3 {tx}

  @p{««}The entire transaction is signed. See: @s{(link)} for the rules.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0900}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 19:10:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7755.msg113114@s{hash}msg113114
@section 3 {tx}

  @p{««}Fine, the entire transaction except for: @p{»»}

    @p{(li}"The scripts for all transaction inputs in txCopy are set to
    empty scripts" @p{li)}

  @p{««}... is signed. You're starting to make me grumpy... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0901}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 19:19:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7757.msg113127@s{hash}msg113127
@section 3 {tx}

  @s{quotedtext}

  @p{««} Have you done any benchmarking to see if that is true? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0902}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-09 19:47:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7758.msg113151@s{hash}msg113151
@section 3 {tx}

  @p{««} @s{(link)} @p{»»}

  @p{««}This pull is prompted by changes I'm making to ClearCoin, and
  should apply to any service where customers will owe the service
  bitcoins. It removes the account balance checks from the RPC move
  command. @p{»»}

  @p{««}I'll use it to create accounts associated with users that keep
  track of how many bitcoins they owe; for example, if I owed 1 bitcoin
  ClearCoin will tell bitcoin: @p{»»}

    @p{(li}move 'gavinandresen' 'total_owed' 1.00 @p{li)}

  @p{««}Assuming I'm not carrying a balance, that makes the gavinandresen
  account balance -1.00 BTC. When I pay to one of the addresses associated
  with the 'gavinandresen' account, the account balance will be
  automatically credited. @p{»»}

  @p{««}If I were a professional accountant I probably would have written
  'move' this way to begin with... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0903}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-10 13:05:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7820.msg114247@s{hash}msg114247
@section 3 {tx}

  @s{quotedtext}

  @p{««} Extending the getnewaddress RPC call to take a (count) parameter
  would be easy. Doing the same for the GUI would be pretty easy, too...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0904}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-10 21:31:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7868.msg114895@s{hash}msg114895
@section 3 {tx}

  @p{««}I shoulda butted in, I think I'm too polite to be on a show with
  Jason Calacanis... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0905}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 01:18:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg115190@s{hash}msg115190
@section 3 {tx}

  @p{««}Golly, journeyofrivers is really going to hate me when he finds out
  I'm an Elected Official and a Cog in the System. Last night I voted to
  steal millions of dollars from taxpayers and give it to public (I know!
  Terrible!) schools. @p{»»}

  @p{««}(I'm only barely an elected official, one of 251 elected Amherst
  Town Meeting members. My punishment is long boring meetings late at
  night a couple times a year...) @p{»»}

  @p{««}Seriously, we probably agree on most things on a philosophical
  level. I just believe I'll get farther by taking "small steps to a much
  better world." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0906}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 01:22:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7901.msg115194@s{hash}msg115194
@section 3 {tx}

  @p{««}Sure, I'd like to see a lot more banging on the testnet to try to
  break it. @p{»»}

  @p{««}(python code is not obfuscated, I assume). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0907}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 01:35:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7897.msg115206@s{hash}msg115206
@section 3 {tx}

  @p{««}bitcredit: do you have ideas or suggestions? @p{»»}

  @p{««}I think a global currency like bitcoin will do a lot to promote
  understanding and diversity, but did you have something specific in
  mind? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0908}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 01:57:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7907.msg115231@s{hash}msg115231
@section 3 {tx}

  @p{««}giraffe.heliacal.net is also known as irc.lfnet.org @p{»»}

  @s{code}

  @p{««} Laszlo runs that IRC chat server, and bitcoin uses it to
  "bootstrap" to find other machines running bitcoin. @p{»»}

  @p{««}Unless you run with the -noirc switch, in which case it won't
  @p{--} it will try to connect via a list of compiled-in 'seed nodes'
  (which I'll try really hard to remember to recruit somebody to update
  for the next release). @p{»»}

  @p{««}After you've run bitcoin once, it stores nodes you were able to
  connect with in the addr.dat file, so you can run -noirc just fine. But
  if everybody did that, newbies who just downloaded bitcoin would have a
  hard time finding people to connect with. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0909}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 02:12:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7904.msg115249@s{hash}msg115249
@section 3 {tx}

  @p{««}Wait a while and they will be free again. @p{»»}

  @p{««}If you are sending 1 BTC (that you just received) in a 250 byte
  transaction, you need to wait 24 hours (1 day). @p{brk} Send 0.25 BTC,
  you'll need to wait 4 days. @p{brk} Send just 0.01 BTC as a 250 byte
  transaction, and you need to wait 100 days before you'll be allowed to
  send it for free. @p{»»}

  @p{««}priority is calculated as: @s{hash}BTC * @s{hash}confirmations / transaction
  size. @p{brk} Very-low-priority is defined as less than 1 * 144 / 250 (1
  BTC, 144 confirmations == 24 hours, 250 bytes), and they require a fee.
  @p{»»}

  @p{««}The tentative plan is for fees to be reduced to @p{(so}5 mils
  (0.005 BTC)@p{so)} half a mil (0.0005 BTC) for the next release.
  Changing the definition of "very low priority" at the same time probably
  makes sense. @p{»»}

  @p{««}(corrected proposed fee)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0910}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 12:11:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7724.msg115800@s{hash}msg115800
@section 3 {tx}

  @s{quotedtext}

  @p{««} So whenever you meet (or communicate with) somebody who owns
  bitbills check your bills' public address against their bills' public
  address. If there is significant counterfeiting going on, eventually
  you'll find a match. Try to redeem both and you'll quickly find out
  which is real and which is counterfeit (or that both are counterfeit).
  @p{»»}

  @p{««}I was going to suggest creating a public Google Documents doc where
  people could enter their bitbill public keys, but griefers could just
  look at the block chain and pretend that they were holding bitbills that
  they don't actually own. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0911}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 13:53:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1865.msg115890@s{hash}msg115890
@section 3 {tx}

  @p{««}I'd tweak the formula to be: max block size = 1000000 +
  (int64)(difficulty) @p{»»}

  @p{««}... just to avoid "if block number is @p{lt} X max block size =
  1000000 else..." logic. Adding in the current 1MB max limit means all
  the old blocks are valid under the new rule. @p{»»}

  @p{««}I like Mike's point that difficulty and transaction volume aren't
  necessarily related. Maybe a better formula for miners would be
  something like: @p{»»}

  @p{««}max block size = 1000000 + (average size of last N blocks in the
  best chain) @p{brk} ... where N is maybe 144 (smooth over 24-hours of
  transactions) @p{»»}

  @p{««}Anybody have access to what Visa daily transaction volume looks
  like in the days around Christmas? Are there huge, sudden spikes that
  the above formula wouldn't handle?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0912}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 15:56:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7945.msg116042@s{hash}msg116042
@section 3 {tx}

  @p{««}If I were going to implement it... hmm... @p{»»}

  @p{««}I think I'd just special-case the genesis block, so it has a value
  out of, oh, I dunno, 20 million CompleCoins. Then maybe fix the mining
  reward to something small and constant (say 0.001 CompleCoin per block,
  forever@p{--} or whatever you like). @p{»»}

  @p{««}The central authority would create the genesis block, and so would
  have 20 million CompleCoins that it could issue (aka spend) however it
  pleased. @p{»»}

  @p{««}The risk would be the central issuer ever losing control of its
  wallet/private key. That risk could be mitigated a little bit by
  occasionally changing the key by spending all of the non-issued coins to
  a new address in a new, secure wallet somewhere and waiting a few blocks
  for confirmation. @p{»»}

  @p{««}I'm having lunch today with somebody else who is interested in
  using bitcoin tech for a centrally issued alternative currency, so I've
  been thinking a bit about it... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0913}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 19:18:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7972.msg116302@s{hash}msg116302
@section 3 {tx}

  @p{««}Raw dump of the notes I got from Satoshi with the headersonly patch
  (which is in the git tree as headersonly branch): @p{»»}

  @s{quotedtext}

  @p{««} My plan was to dive into what Satoshi wrote already, understand
  it, test it in fClient=true mode (sending/receiving/relaying
  transactions on testnet), fix whatever is broken/unimplemented. @p{»»}

  @p{««}And then write code to switch from fClient=true to fClient=false,
  downloading full blocks, etc. And then writing code that does the toggle
  when generation is turned on for the first time or when getwork is
  called (I think those are the only times you need full blocks). @p{»»}

  @p{««}I haven't looked at or thought about the relaying code. Simply
  relaying all transactions (without checking to see if they're valid) if
  fClient=true should work nicely. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0914}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 20:37:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7984.msg116407@s{hash}msg116407
@section 3 {tx}

  @p{««}I've been working on making the ClearCoin escrow service's fee
  structure simpler; here's the new structure, which will "go live" in the
  next day or two: @p{»»}

  @p{««}ClearCoin costs 0.5% (one half of one percent) of released coins.
  For example, if you are paying for something worth 100 bitcoins the cost
  will be 0.5 BTC. @p{»»}

  @p{««}Fees are paid only on released coins; no fees are charged on coins
  donated to charity or refunded to you. @p{»»}

  @p{««}Coins in escrow will never be taken or held if you have unpaid
  fees; if you do not pay your ClearCoin fees within 30 days we may
  prevent you from creating new escrow transactions but will never prevent
  you from releasing coins from existing escrow accounts. However, given
  how quickly the value of bitcoins has been increasing recently, it is
  better for you to pay your ClearCoin fees quickly. @p{»»}

  @p{««}Any month you accumulate more than a trivial amount of fees
  ClearCoin will email you an invoice with a detailed list and a bitcoin
  address to which you can send payment. You can also pay at any time by
  sending bitcoins to an address on the ClearCoin website. @p{»»}

  @p{««} All of these changes were prompted because I think it was
  confusing to pay fees directly from the bitcoins being used for the
  transactions@p{--} if you were paying for something that cost 159.95
  BTC, calculating how much to send to pay for the cost AND ClearCoin fees
  was complicated. This should also be much easier for anybody creating a
  lot of ClearCoin transactions via the new @p{(link}ClearCoin
  API@p{link)}. @p{»»}

  @p{««}As always, feedback, complaints, and suggestions are welcome. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0915}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 21:28:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7984.msg116487@s{hash}msg116487
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because that requires that you do some math to figure out how many
  to send to pay the escrow plus release the right amount. @p{»»}

  @p{««}And because I'm planning on eventually implementing "receiver
  creates and pays" escrow transactions, so merchants can setup escrow
  transactions (via the API) for their customers. Merchants are used to
  paying fees as just a cost of doing business. @p{»»}

  @p{««}RE: how will I prevent you from creating new escrow transactions if
  you don't pay? Click on "Create Escrow" and you'll be taken to a page
  that politely explains you're not allowed until you pay. If you use the
  API, the create_escrow call will fail. @p{»»}

  @p{««}I realize some people may try to cheat by using/creating multiple
  Google accounts. That will be a cost of doing business for me. Perhaps I
  will reserve the right to publish deadbeat account email addresses on a
  "hall of shame..." (I'd implement a Terms of Service Agreement to which
  you would have to agree before creating a new escrow) @p{»»}

  @p{««}RE: will this affect coins in existing escrow accounts: @p{»»}

  @p{««}No, existing escrow accounts will be unaffected, these new rules
  will be for new escrow accounts only.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0916}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-11 23:23:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7972.msg116652@s{hash}msg116652
@section 3 {tx}

  @p{««}All this talk about neato-spiffy future hub-and-spoke
  supernodes-and-leaves architecture is great. @p{»»}

  @p{««}But I was kinda thinking of first solving the problem that anybody
  who just wants to download the client, get a few coins from a friend,
  and then spend them on something has to wait a very long time right now.
  That doesn't require any re-architecting of the system or any new
  networking messages, and should make the "out of the box" bitcoin
  experience much better for lots of people. @p{»»}

  @p{««}And it is a step towards a future neato-spiffy Uber-efficient
  hyper++client. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0917}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-12 16:48:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8051.msg117573@s{hash}msg117573
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's actually a very hard attack to successfully pull off; I
  file it under "theoretically worrisome, but practically not a high
  priority." @p{»»}

  @p{««}It is hard because: @p{»»}

    @p{(li}@p{(li} targeting a particular node is hard. The long-running
    nodes that you probably want to target (merchants or exchangers or
    e-wallet services, where double-spending could get you a significant
    number of bitcoins) will already have 50+ connections to legitimate
    nodes, and an addr.dat full of the addresses/ports of legitimate
    nodes. @p{li)}

  @p{(li}  you have to feed the target a bogus version of the block chain.
  And you won't be able to feed them new blocks very fast, because
  difficulty is so high (unless you invest a ton of hashing power to
  generate bogus blocks... but that's stupid, you're wasting money mining
  worthless blocks so you can try to pull off a probably-low-value
  double-spend???). Anybody you target is going to wonder why their
  transactions are taking so long to confirm and why their block count is
  falling behind everybody else's.  @p{li)}

  @s{quotedtext}

  @p{««} Putting a few addnode=... to connect to trusted nodes (with static
  IP addresses) at startup in your bitcoin.conf is a good idea. @p{»»}

  @p{««}For (3), detecting dramatic,
  statistically-nearly-impossible-normally changes in the hashing rate is
  a better way to detect sybil attacks. That's on my personal "it'd be
  nice to have" list (because, as I said, I don't think this is a big
  threat). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0918}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-12 22:06:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8090.msg118069@s{hash}msg118069
@section 3 {tx}

  @p{««}Why would you "bring up the issue" ? @p{»»}

  @p{««}Just declare bitcoin-related income or capital gains as income, and
  bitcoin-related expenses as expenses, translated into units that the IRS
  understands (dollars), and follow the rules for WHEN you must declare
  income, capital gains and expenses and I bet a bitcoin you'll be just
  fine, even if you get audited. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0919}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-12 23:55:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8048.msg118191@s{hash}msg118191
@section 3 {tx}

  @p{««}Your 0.07 transaction is very-low-priority, and still waiting to
  get in a block. From bitcoincharts: @p{»»}

  @p{««}Code: 2011-05-11 15:34:58
  2cf664377d1923089d0aed9d7aab3f8d51f69c76409a71e3d88b378a13e3612e @p{brk}
  This is a low priority transaction. @p{brk} size: 258 bytes @p{brk}
  priority: 12,250,000 @p{brk} input: 0.12900000 BTC @p{brk} 0.12900000
  BTC from
  9bea18121283bc7f9618eb8b50ce94e9df4698eb51468152fa686bfe94387d2d:0
  (1CM9WjjPScLSfQaYXq9YY5VgqUh6bP87rw) @p{brk} output: 0.12900000 BTC
  @p{brk} 0.07000000 BTC to 1KCJ79R4CexWmqK6qa2HBeFv8bG3a3wAfX @p{brk}
  0.05900000 BTC to 14Q7k5u5UAhEWC5E52BGwLVFKWeW3ffBtA @p{»»}

  @p{««} It might take a few days, but it will eventually get confirmed.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0920}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 00:33:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7897.msg118230@s{hash}msg118230
@section 3 {tx}

  @s{quotedtext}

  @p{««} Neat idea! All sorts of chicken-and-egg hurdles to overcome (what
  good is a bitcoin loan if there is nothing to spend the bitcoins on?),
  but microlending bitcoins would be great. I'm spread a little thin at
  the moment, but if you think a conversation with kiva right now might be
  worthwhile then go for it. You don't need anybody's permission or advice
  to become the Bitcoin-Kiva Liason Officer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0921}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 00:47:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7351.msg118241@s{hash}msg118241
@section 3 {tx}

  @s{quotedtext}

  @p{««} The input-transaction-selection algorithm in bitcoin tries to use
  older transactions, which will have higher priority. @p{»»}

  @p{««}I'd guess that online wallets with lots of users have plenty of old
  transaction to choose from, so they don't need to pay transaction fees.
  Actually, it'd be interesting to try to measure how quickly the average
  bitcoin in an e-wallet stays in the wallet before being used for an
  outgoing transaction... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0922}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 00:49:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8098.msg118245@s{hash}msg118245
@section 3 {tx}

  @p{««}-nolisten turns on -noirc. @p{»»}

  @p{««}Try: @p{»»}

  @p{««}addnode=69.164.218.197 @p{»»}

  @p{««}... to connect to the testnet Faucet bitcoind. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0923}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 11:28:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8126.msg118965@s{hash}msg118965
@section 3 {tx}

  @p{««}In the future, there will be many more than 4,000 transactions per
  block. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0924}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 12:50:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8153.msg119033@s{hash}msg119033
@section 3 {tx}

  @p{««}The send RPC methods return a transaction id. @p{»»}

  @p{««}Pass the transaction id to the gettransaction RPC method, and it
  will give you details of the transaction, including what fees were paid.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0925}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 12:53:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8148.msg119034@s{hash}msg119034
@section 3 {tx}

  @p{««}Looks ok to me, assuming $account and $address are strings and
  $amount is a number. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0926}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-13 15:47:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8153.msg119301@s{hash}msg119301
@section 3 {tx}

  @p{««}Oh, and what version of bitcoin are you running? 0.3.21 includes a
  patch from luke-jr that modifies the coin-selection algorithm to avoid
  sub-cent change when possible. @p{»»}

  @p{««}It will also help if you keep a good selection of 'old' coins in
  the shared wallet. @p{»»}

  @p{««}I agree that transaction fee accounting/handling needs improvement.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0927}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-14 20:43:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8227.msg121092@s{hash}msg121092
@section 3 {tx}

  @p{««}This is where I think maybe a standard https-based protocol might
  work nicely, so the same address shortening services can be used either
  in the bitcoin client and for online e-wallets. @p{»»}

  @p{««}Something simple, like user says "Please use these services for
  resolving addresses: @p{»»}

    @p{(li} @s{(link)} @p{li)}

    @p{(li} @s{(link)} @p{li)}

    @p{(li} @s{(link)} @p{li)} " @p{»»}

  @p{««}Protocol could just be POST the text the user types into the
  address field and get back JSON with a bitcoin address and maybe some
  extra information to reassure the user that they're paying
  @p{(link}gavin@s{at}acm.org@p{link)} "Gavin Andresen (my picture) (my gpg key
  fingerprint)" and not @p{(link}gaven@s{at}acm.org@p{link)} "Gaven Smith (some
  other guy's picture) (no gpg key fingerprint)" ... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0928}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-14 21:00:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7945.msg121108@s{hash}msg121108
@section 3 {tx}

  @s{quotedtext}

  @p{««} If you're willing to muck with the transaction processing code,
  you could only allow transactions to addresses that have been created
  and blessed by the Central Authority. You'd have to also teach the
  wallet code not to create lots of addresses, but if you're going to
  require users to register and not be anonymous you might as well
  centrally create and issue them their wallets. @p{»»}

  @p{««}You then need a mechanism to broadcast new, blessed public keys to
  the entire network, but that might be as simple as generating a
  transaction from a baked-in blessed address (owed by the Central
  Authority) to the newly created blessed address. @p{»»}

  @p{««}Implementing and debugging would be a lot of work, and I'd be
  nervous about neglecting some little detail and leaving the system open
  to hacks (Bitcoin is nice because so many people are extremely motivated
  to find any chink in the system and either exploit it or patch it@p{--}
  a small complementary currency wouldn't have that advantage). But it
  could be done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0929}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 00:53:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8307.msg121434@s{hash}msg121434
@section 3 {tx}

  @p{««}I make the Amazon virtual machine images that I used to build the
  Windows and Linux binaries available... but Amazon recently took them
  down because they contain my ssh public key in the "allowed to login
  without a password" file. Removing the public key and then making the
  modified virtual machines public again is on my TODO list (Amazon
  doesn't want anybody to have a 'back door' into a public machine image,
  and bravo to them for checking@p{--} I had no intention of logging into
  other's bitcoin-build-environment virtual machines, I just needed an
  easy way to login while I was putting together the releases). @p{»»}

  @p{««}If you have an EC2 account, you can run them and recreate the exact
  build environment and check to make sure you get exactly the same
  executable code (the compilers may put timestamps inside the files which
  you'd have to ignore). @p{»»}

  @p{««}The plan for future releases is to use devrandom's 'gitian' build
   system, which is a spiffy way of creating a well-defined virtual
   machine image from signed and trusted repositories, fetching a specific
   version of the code from the git source tree, and compiling in a way
   that is completely reproducible. @p{brk} See: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0930}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 00:57:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8091.msg121440@s{hash}msg121440
@section 3 {tx}

  @s{quotedtext}

  @p{««} That'd be exactly when the power goes out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0931}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 00:58:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8211.msg121441@s{hash}msg121441
@section 3 {tx}

  @p{««}daemon=1 @p{brk} ... is the right syntax for the conf file. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0932}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 01:57:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8282.msg121495@s{hash}msg121495
@section 3 {tx}

  @p{««}I like "mills" or "millies". @p{»»}

  @p{««}The new default transaction fee is 5 mills per kilobyte, by the
  way. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0933}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 18:05:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8392.msg122487@s{hash}msg122487
@section 3 {tx}

  @p{««}I think sipa is right@p{--} it will just look like a weird
  double-spend. @p{»»}

  @p{««}Probably a good idea to reject transactions with non-canonical
  signatures (reject if encode(decode(tx)) != tx ). @p{»»}

  @p{««}I assume the DER-encoded ASN.1 octet representation is the same
  between different ECDSA implementations (so if a non-openssl-based
  implementation creates transactions its transactions would be accepted),
  is that a good assumption? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0934}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-15 23:05:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8340.msg122924@s{hash}msg122924
@section 3 {tx}

  @p{««}Yep, if you control more than 50% of the hashing power you can just
  refuse to work on anybody else's blocks and your chain will always
  eventually be the longest. @p{»»}

  @p{««}Of course, if you do that there will be constant block chain splits
  and transaction confirmations will take twice as long (because you'd be
  throwing away the other half of the network's hashing power), so we'd
  all notice. @p{»»}

  @p{««}And I'm pretty confident we'd think of an effective way to ignore
  your blocks. Seems like an awfully big risk for a +50% pool operator to
  take; why would they want to undermine the system that is (almost
  certainly) making them lots of money? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0935}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-16 22:25:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5587.msg124180@s{hash}msg124180
@section 3 {tx}

  @p{««}Good, that looks like it will be easy to find.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0936}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-16 22:44:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8432.msg124209@s{hash}msg124209
@section 3 {tx}

  @p{««}Yes, the 0.3.21 release will charge a fee if you want to do things
  like send 0.05 bitcoins to yourself. @p{»»}

  @p{««}Why? Because some people were sending 0.05 BTC to themselves over
  and over and over again, wasting everybody's disk space, bandwidth, and
  CPU time. The fee is there to reveal the hidden costs of sending lots of
  tiny transactions. @p{»»}

  @p{««}Next release the normal fee will be dropped from 0.01 BTC to 0.0005
  BTC. @p{»»}

  @p{««}The long-term goal is to figure out how to make fees dynamic; maybe
  in a few months you'll get a slider that lets you choose fees on a
  transaction-by-transaction basis, and will show you how long you're
  likely to wait for various amounts of fees... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0937}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-17 17:47:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6189.msg125734@s{hash}msg125734
@section 3 {tx}

  @s{quotedtext}

  @p{««} Downgrading does not "fix" it. The earlier version would broadcast
  the transaction, and then it would (most likely) either sit in the
  network with 0 confirmations for half a day or sit on your machine with
  0 confirmations for a few hours, until it aged enough to graduate from
  the 'very low priority' category. @p{»»}

  @p{««}The rule of thumb is 1 BTC you just received needs 144
  confirmations (1 day) before it is considered 'normal priority.' 10
  bitcoins requires 1/10'th that@p{--} 15 confirmations would do it. @p{»»}

  @p{««}Given the recent rise in bitcoin value, I think it makes sense to
  modify that formula so 1 BTC takes (perhaps) 10 confirmations to be
  considered 'not likely to be spam'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0938}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-17 22:00:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8636.msg126209@s{hash}msg126209
@section 3 {tx}

  @p{««}To get even more "meta" : ask yourself why @p{(it}anything@p{it)}
  has value. @p{»»}

  @p{««}Tools, like hammers or cars or pants, have value mostly because
  they're useful and it takes effort to create them. @p{»»}

  @p{««}Some things have value because they're beautiful or rare. @p{»»}

  @p{««}Bitcoins have value because they are useful and rare. As more and
  more people use them, they're useful for more and more things@p{--} so
  their value will increase. A lot of the current value of bitcoin is
  people who realize this and are trying to 'buy in early' @p{--} they
  think that bitcoin will be used for more trading next year, so the value
  will be higher, so they want to get some now before the price rises.
  @p{»»}

  @p{««}I have no idea what the "right" value for bitcoin is, but I am very
  encouraged by all of the fantastic, innovative ways people are using
  bitcoin. I expect most of those experiments will fail, and I hope that
  everybody realizes that there will be lots of failures along the way to
  what I hope will be a huge success. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0939}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 00:15:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8728.msg126415@s{hash}msg126415
@section 3 {tx}

  @p{««}Random thought RE: passwords and RPC: @p{»»}

  @p{««}I was thinking a better way of handling the password might be a new
  RPC command: @p{»»}

  @p{««}walletpassword @p{lt}password@s{gt} @p{lt}timeout@s{gt} @p{»»}

  @p{««}... which would store @p{lt}password@s{gt} in memory for
  @p{lt}timeout@s{gt} seconds. If you know your server is secure, you'd
  give a very long @p{lt}timeout@s{gt} at startup. @p{»»}

  @p{««}That same @p{lt}timeout@s{gt} mechanism might be very handy in the
  GUI (somebody who knows more about password security might have
  something intelligent to say about the tradeoff between the risk of
  storing hashed-password in memory versus the convenience of not having
  to constantly re-enter it). @p{»»}

  @p{««}A walletpasswordchange @p{lt}oldpassword@s{gt}
  @p{lt}newpassword@s{gt} seems like it would be very handy, too. @p{»»}

  @p{««}Tacking @p{lt}password@s{gt} onto the beginning of RPC argument
  lists seems like the wrong thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0940}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 00:29:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8689.msg126444@s{hash}msg126444
@section 3 {tx}

  @s{quotedtext}

  @p{««}People keep saying that, but it is simply not true. @p{»»}

  @p{««}With a given number of "front-end" CPUs checking ECDSA transaction
  signatures, miners will be able to process at most N transactions per
  second. @p{»»}

  @p{««}If there are more transactions than that going over the network,
  then miners will drop the least-profitable transactions and only process
  the most-profitable N. @p{»»}

  @p{««}Mining involves two distinct tasks: checking transactions and
  gathering them into a block (which is inexpensive right now because
  there aren't gazillions of transactions). And then hashing (which will
  always be expensive). @p{»»}

  @p{««} Miner operators will keep track of the transactions they're
  dropping, and will do some math to figure out if it would be profitable
  for them to invest in MORE front-end CPUs to process more than N
  transactions per second. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0941}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 00:44:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8672.msg126463@s{hash}msg126463
@section 3 {tx}

  @s{quotedtext}

  @p{««} To be completely sure you get all the donations you deserve, you
  should put the donation address on an http@p{(bf}s@p{bf)}:// page. @p{»»}

  @p{««}Otherwise hackers can hijack http: pages if they can insert
  themselves into the network between you and your web visitors, and
  replace the donation address on the webpage with their bitcoin
  address.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0942}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 01:21:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8617.msg126519@s{hash}msg126519
@section 3 {tx}

  @p{««}My rule of thumb is "never inline methods more than 1 line long."
  @p{»»}

  @p{««}Unless you're doing something super performance-critical, in which
  case my rule of thumb is "don't change anything until after you've
  written a realistic benchmark." @p{»»}

  @p{««}But I'm an old-fashioned C++ coder, kids these days seem to want to
  put all the code in .hpp files. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0943}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 12:57:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8363.msg127215@s{hash}msg127215
@section 3 {tx}

  @p{««}In the long run, block size will NOT be the bottleneck, so it will
  NOT determine the marginal cost of a transaction. @p{»»}

  @p{««}The bottleneck is, and I believe will continue to be, the number of
  ECDSA signature verifications a miner can perform per second. Each miner
  (or mining pool operator) will have a transaction processing capacity of
  N transactions per second. @p{»»}

  @p{««}If there are more than N transactions per second going across the
  network, then the smart miners will select the most profitable N for
  inclusion in their blocks and drop the least profitable. @p{»»}

  @p{««}And the smart miners will keep track of how much it would cost them
  to invest in more CPUs or specialized ECDSA-verification hardware so
  they can process N+M transactions per second. And figure out how much
  they would make in fees or side-deals (or whatever) when they handle
  those extra M transactions per second. If it is profitable, they will
  increase their transaction processing capacity. @p{»»}

  @p{««} @p{hrule} I think what bitcoin is missing right now is code in the
  clients to figure out the "right" amount of fees. We're currently
  relying on hard-coded rules that match in the client and in the miners
  (because it was All One Application to start). We need to move to
  something more dynamic. Some thoughts I jotted down last night: @p{»»}

  @p{««}Users want to know what fee to pay, given the constraints "I want
  this transaction confirmed in B or fewer blocks with probability greater
  than P". @p{»»}

  @p{««}If we think of that as an equation: @p{»»}

  @p{««}Code: fee = f(txn, B, P) ... then the question is can a client
  estimate f by looking at the block chain and/or observing transactions
  as they fly across the network and (eventually) get included in blocks?
  Or can we come up with a protocol to communicate f between clients and
  miners? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0944}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 13:05:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8728.msg127225@s{hash}msg127225
@section 3 {tx}

  @p{««}Would it be good enough if I volunteered to write a little perl or
  python or php or bash script that reads the passphrase from a file
  descriptor and then posts the right JSON-HTTP request? @p{»»}

  @p{««}If the consensus is to teach bitcoind to read arguments from file
  descriptors, somebody please figure out if there's a standard for how
  other unix apps do that. Here's what curl does: @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms0945}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 15:00:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8363.msg127432@s{hash}msg127432
@section 3 {tx}

  @s{quotedtext}

  @p{««} They haven't paid the ECDSA price. The decision is "I know how big
  this transaction, how many OP_CHECKSIG opcodes I'll have to compute to
  verify it, and how much transaction fees it pays. Should I do the work
  of verifying it or should I just ignore it?" @p{»»}

  @p{««} ribuck: yes, the UI would be much simpler, but internally the
  client needs a model of what the miners are accepting. Maybe a really
  simple internal model will work if the UI is really simple...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0946}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 15:12:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8737.msg127449@s{hash}msg127449
@section 3 {tx}

  @p{««}My advice: don't reinvent the wheel. There are already standards
  and organizations dedicated to security practices surrounding currency,
  both physical and virtual, and financial transactions. It doesn't really
  matter if the currency is bhat or bitcoin, the principles will be the
  same. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0947}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 17:24:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8737.msg127739@s{hash}msg127739
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, no, no and yes. I'm planning on making the answers to all of
  those questions "yes" within the next six months, although I need to
  look at how many bitcoins are contained at any given time in the
  ClearCoin wallet; it might make more sense to send double or triple that
  amount of bitcoin to a publicly verifiable address, prove I own the
  coins, and guarantee any losses due to ClearCoin getting hacked. @p{»»}

  @p{««}(note: I just looked, and right now there are 540 bitcoins in the
  ClearCoin wallet, so spending $50,000 to protect them really wouldn't
  make sense). @p{»»}

  @s{quotedtext}

  @p{««} Yet another bitcoin chicken-and-egg problem that will get solved
  by investors taking a risk and giving bitcoin entrepreneurs the
  resources to do security right (or wealthy entrepreneurs stepping up and
  making the investment themselves).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0948}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 18:13:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8714.msg127840@s{hash}msg127840
@section 3 {tx}

  @p{««}Just think of that guy who gave away 10,000 bitcoins through the
  Bitcoin Faucet... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0949}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-18 18:37:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8799.msg127897@s{hash}msg127897
@section 3 {tx}

  @s{quotedtext}

  @p{««} That is exactly what -connect does (if I recall correctly; you
  might need -connect and -nolisten together). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0950}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-19 04:00:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3262.msg128896@s{hash}msg128896
@section 3 {tx}

  @s{quotedtext}

  @p{««}Sure, we'll call it GavinCoin and I get all the coins to start.
  @p{»»}

  @p{««}If you want some, you just send me some of that worthless fiat
  currency that you have laying around. @p{»»}

  @p{««}Sound good? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0951}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-19 14:30:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8865.msg129571@s{hash}msg129571
@section 3 {tx}

  @p{««}I'd suggest removing/replacing the "it is anonymous" claim. @p{brk}
  Anonymity and bitcoin is...complicated. I'd suggest: @p{»»}

  @p{««}"It is like cash" @p{--} no one can steal your identity @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0952}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-19 15:08:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8940.msg129623@s{hash}msg129623
@section 3 {tx}

  @p{««}So with the recent avalanche of press interest in bitcoin, I
  thought I'd share my thoughts on how I'd like to see bitcoin positioned.
  I'm not writing this as "This is the Official Bitcoin Organization
  Position" @p{--} as always, I expect everybody to have, and express,
  their own views. @p{»»}

  @p{««}I'll restate what I see as the goal of The Bitcoin Project: To give
  us control over our finances by establishing a stable, secure, global,
  "democratic" currency. @p{»»}

  @p{««}I think positioning bitcoin as "revolutionizing the financial
  system" is the goal@p{--} not more radical statement I've heard (like
  "destabilizing governments"). Most people either like or are indifferent
  to their governments (I know, I know, sheeple and all that... lets not
  go there). I don't think most people get the warm fuzzies when thinking
  about bankers and Big Corporations; bitcoin as "The People's Money" is
  the right way to think about it. @p{»»}

  @p{««}Also, whenever I talk to the press, I try to be realistic. Bitcoin
  is still an experiment that has never been tried before; there is still
  a good chance it will fail, and there is still a lot of work to do to
  make it stable and secure. I'm excited because bitcoin is a big idea
  that might change the world for the better, but I also realize that our
  little project is just a baby compared to the decades-old financial
  systems that we all use every day. @p{»»}

  @p{««}I think it is important to set expectations; I still wouldn't
  recommend that my mom use bitcoin for @p{(it}anything@p{it)} just yet,
  because it is not easy enough to use securely. And the road ahead is
  likely to be bumpy; there will be technical issues that need fixing,
  there will be legal questions, there will be price bubbles, and there
  will be scams. I predict that some company using bitcoins to do
  something illegal will be caught and prosecuted, and that will be
  mis-reported as "Bitcoin is illegal." @p{»»}

  @p{««}I said a year ago that creating solid technology was just the first
  step in a long road for bitcoin. I'm very pleasantly surprised at how
  far the bitcoin project has come in a year; the innovation and
  experimentation and level of interest and excitement is fantastic. @p{»»}

  @p{««} Here's an email exchange I had with a reporter yesterday: @p{»»}

  @s{quotedtext}

  @p{««} New technologies are always at least a little bit dangerous@p{--}
  they can usually be used for both good and bad (think of gunpowder or
  ChatRoulette), and are certainly dangerous to the status-quo that they
  replace (think of cars and buggy-whip-manufacturers). @p{»»}

  @p{««}Bitcoin is a really ambitious project; we're trying to let people
  take back control of their money instead of trusting bureaucrats or
  bankers or politicians to keep it stable and safe. It is international,
  decentralized, and completely open to innovation, very much like the
  Internet. Like the Internet, I expect its early years to be full of
  amazing successes and spectacular failures, and I don't think anybody
  will be able to predict in advance what will succeed and what will fail.
  @p{»»}

  @p{««}I think the real question is whether or not bitcoin will appeal to
  the majority of people who are happy with our current financial system.
  If it doesn't, bitcoin may fade away or end up as a niche currency used
  for a tiny percentage of global financial transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0953}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-22 07:56:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg134720@s{hash}msg134720
@section 3 {tx}

  @p{««}I'm just quiet because I've been busy being jet-lagged and
  sightseeing in Paris.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0954}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-23 14:29:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9495.msg137055@s{hash}msg137055
@section 3 {tx}

  @p{««}If I understood the paper correctly (I skimmed it very quickly),
  this is a timing attack that requires the attacker send a bunch of
  things to be @p{(bf}signed@p{bf)} with the same ECDSA private key. @p{»»}

  @p{««}The good news is it they also give a patch to OpenSSL to fix it.
  The other good news is bitcoin only signs things with private keys when
  you send coins, and if you have the ability to ask bitcoin to send coins
  then we don't really care if you can get the private key. @p{»»}

  @p{««}We do have a patch in the "pull queue" that adds a RPC command to
  let bitcoin sign stuff ( @s{(link)} ), but, again assuming I read the
  paper correctly, even that doesn't worry me, since if you have the
  ability to run that RPC command you could either go through all the
  trouble of the timing attack to figure out the private key... or you
  could just issue a "send" command to steal all the bitcoins out of the
  wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0955}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-23 14:37:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9334.msg137064@s{hash}msg137064
@section 3 {tx}

  @p{««}I vote for removing dead code; less code means less bugs, and less
  chance of security issues. The source control system is the right place
  for code that we "might need again someday..." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0956}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-23 14:48:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62.msg137077@s{hash}msg137077
@section 3 {tx}

  @p{««}RE: moving to another hashing algorithm for bitcoin addresses:
  @p{»»}

  @p{««}Did you read what Satoshi wrote? @p{»»}

  @p{««}If you want to make money, you are far, far, far, far, far, far
  better off using your hardware to generate blocks than trying to find a
  bitcoin address collision and steal bitcoins. Potential address
  collisions are not a weakness, and switching to another algorithm would
  be just busy-work for us developers who should be spending time on REAL
  weaknesses (like figuring out how to make bitcoin more secure against
  trojans and viruses). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0957}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-23 20:11:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7421.msg137583@s{hash}msg137583
@section 3 {tx}

  @p{««}The only reason I can think of is it relies on the boost::xpressive
  regular expression parsing .hpp, and that slows down the build. @p{»»}

  @p{««}I did refactor most of this into a rpcmonitor.cpp file; rpc.cpp was
  getting huge, and was taking a ton of memory and time to compile. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0958}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-24 08:16:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9295.msg138588@s{hash}msg138588
@section 3 {tx}

  @p{««}If processing old transactions becomes expensive, then miners will
  start charging transaction fees to include them in their blocks. @p{»»}

  @p{««}Speculating about exactly HOW the miners will charge (will they
  subscribe to an 'old transaction service' or somehow contact the
  old-transaction-spender for the merkle branch of the old transaction?)
  is a waste of time, in my humble opinion. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0959}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-24 19:04:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9680.msg139595@s{hash}msg139595
@section 3 {tx}

  @p{««}Ooh! Ooh! 50 more bitcoins for the "Bitcoins Lost Forever" thread!
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0960}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-24 19:11:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5587.msg139615@s{hash}msg139615
@section 3 {tx}

  @p{««}I'm looking forward to meeting everybody@p{--} I be at the big red
  spider thing at 12:30. @p{»»}

  @p{««}I've got a temporary mobile phone, number is: 06 19887172 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0961}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-24 20:27:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9703.msg139786@s{hash}msg139786
@section 3 {tx}

  @p{««}Search the forums for "Sybil attack" and you'll find relevant
  discussion. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0962}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-25 20:28:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9792.msg142097@s{hash}msg142097
@section 3 {tx}

  @p{««}Bad peer code that drops the connection and refuses reconnection
  seems like a good denial-of-service prevention measure. @p{»»}

  @p{««}My only hesitation is accidentally causing a network (and,
  therefore, block-chain) split if "bad" turns out to be "my peer is
  running a newer version of the protocol and is accidentally sending me
  messages I don't understand." @p{»»}

  @p{««}RE: net neutrality: if you have to worry about your bitcoin traffic
  being shut down, I think that problem is better solved with TOR or
  another network proxy solution. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0963}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-26 07:47:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9863.msg143215@s{hash}msg143215
@section 3 {tx}

  @s{quotedtext}

  @p{««} For debugging your own sites, a testnet-in-a-box setup is nice and
  stable, completely under your control, and has a good supply of mature
  coins to debug with. See @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0964}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-26 08:14:45 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9879.msg143245@s{hash}msg143245
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure. But if They sent you some of the bitcoins that were in that
  wallet then They might be able to track you down when you use those
  coins at a Ferrari dealership that is cooperating with or run by Them.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0965}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-26 21:31:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9933.msg144674@s{hash}msg144674
@section 3 {tx}

  @s{quotedtext}

  @p{««} If the network was split 50/50, then each half would generate
  blocks half as fast. So it would take 34 hours. @p{»»}

  @p{««}For an "Egypt splits off from the rest of the network" scenario, it
  would probably split something like "less than 5% generated in Egypt,
  95% rest of the world" in which case it would take 17/.05 = over two
  weeks for the blocks generated in Egypt to mature. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0966}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-27 08:15:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=9997.msg145609@s{hash}msg145609
@section 3 {tx}

  @p{««}Released, transaction id
  fe5ee70feac0db3963d20fa746257ec18fec7379f90ca6a1ef4c1df564c6e413 @p{»»}

  @p{««}I'm still not sure why they didn't release automatically; they
  should have. Debugging the problem fully will have to wait until I am
  back home on my main development machine. If anybody else has the same
  problem, send me an email and I'll fix it ASAP. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0967}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-27 08:18:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1667.msg145611@s{hash}msg145611
@section 3 {tx}

  @s{quotedtext}

  @p{««}If only the FAQ was a wiki that anybody could edit, then thedrs
  could add it him or herself... @p{»»}

  @p{««}(hey, wait a minute! it IS a wiki!)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0968}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-27 15:16:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg146198@s{hash}msg146198
@section 3 {tx}

  @s{quotedtext}

  @p{««}June 14th at CIA HQ, Langley Virginia. It is not open to the
  public, conference is for the US intelligence community only. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0969}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-27 15:27:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8153.msg146218@s{hash}msg146218
@section 3 {tx}

  @s{quotedtext}

  @p{««}Huh? That's backwards, transaction fees are smaller (as a
  percentage) if you're sending more BTC. Number of bitcoins being sent
  doesn't matter, number of inputs and outputs to the transaction matters.
  @p{»»}

  @p{««}RE: estimating fees beforehand: what is the use case where that is
  actually useful? What do you want the user experience to be? @p{brk} And
  what happens if the estimate turns out to be wrong? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0970}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-28 07:29:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7757.msg147965@s{hash}msg147965
@section 3 {tx}

  @p{««}Sounds like this is good for pool operators that have high
  'getwork' loads@p{--} have any high-volume merchants sites or e-wallet
  sites tried it? @p{»»}

  @p{««}I've got a long list of things to do when I get back from vacation
  week after next, or I'd volunteer to run it on the Faucet to help stress
  test it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0971}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-05-30 18:51:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=10660.msg153042@s{hash}msg153042
@section 3 {tx}

  @p{««}Bitcoin isn't suited for transactions worth less than about one US
  penny@p{--} it wasn't designed or intended for lots of
  micro-transactions. @p{»»}

  @p{««}That said, building a micro-transaction system on top of bitcoin is
  certainly possibly (see witcoin or youtipit for some examples@p{--} or
  see the way the Bitcoin Faucet is handling payments recently, bundling
  up lots of small transactions to send them without paying outrageous
  fees). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0972}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-03 10:28:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11597.msg163457@s{hash}msg163457
@section 3 {tx}

  @p{««}I split this topic from the Public Relations thread. Apologies for
  any mistakes I made selecting which posts to split. @p{»»}

  @p{««}For the record: I think a main block chain reset is a terrible
  idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0973}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-03 10:50:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11318.msg163512@s{hash}msg163512
@section 3 {tx}

  @p{««}I fixed ClearCoin (restarted the bitcoind daemon) as soon as I got
  home; I apologize again for the service interruption. I can't yet
  promise it won't happen again@p{--} I'm still a single point of failure
  for ClearCoin. But I'm working on changing that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0974}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-03 11:58:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11449.msg163634@s{hash}msg163634
@section 3 {tx}

  @p{««}I flagged it as scams/fraud. @p{»»}

  @p{««}It'll be interesting to see if scammers/fraudsters manage to pull
  off many "big scores" @p{--} in the age of instant Internet feedback and
  crowdsourced self-policing, it might be tough. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0975}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-03 15:06:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11491.msg164180@s{hash}msg164180
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, diversity is good. If you do decide to go for it, do lots of
  testing on either the test network or with a testnet-in-a-box setup
  before even THINKING about handling real bitcoins. If you screw up and
  lose other people's money it will take a long time to earn back their
  trust. @p{»»}

  @p{««}Oh, and speaking of trust... unless you have a recognized Brand
  Name, I don't think you'll have any success with a closed-source client.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0976}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-04 10:57:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=10702.msg167154@s{hash}msg167154
@section 3 {tx}

  @s{quotedtext}

  @p{««} Depends on your definition of "micropayment". Bitcoin is not
  suitable for transactions of less than a US penny, because of its fixed
  costs of processing transactions.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0977}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-04 10:58:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11884.msg167155@s{hash}msg167155
@section 3 {tx}

  @p{««}What theymos said. There's another thread about this, too, and I'll
  ask here what I asked there: what is the use case for an 'estimate
  transaction fee' function? What if the estimate is wrong, what would
  your application do? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0978}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-04 18:58:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12033.msg168237@s{hash}msg168237
@section 3 {tx}

  @p{««}Diversifying is a good strategy. @p{»»}

  @p{««}I wouldn't trust that an Internet cafe computer was safe; if I were
  you, I might buy some bitbills ( bitbills.com ) and have them mailed to
  your home address. I ordered some bitbills shortly before I left for
  France and the mailman delivered them to me with the rest of my held
  mail when I got home. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0979}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-04 20:11:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12060.msg168440@s{hash}msg168440
@section 3 {tx}

  @p{««}A huge block-chain re-org on the testnet confused the heck out of
  the testnet faucet (leaving it with lots of 0-confirmation,
  used-to-be-valid sends that made it think it had a negative balance).
  @p{»»}

  @p{««}Clearing its wallet of the 0-confirmation transaction fixed it, but
  left it with a very small balance. It is up and running (at @s{(link)}
  ), but if you generated a bunch of testnet coins, please send some to
  the testnet faucet at miGuMc6qtVEKS6Pf1jKddaa81DeHjMzkpB . @p{»»}

  @p{««}Also, for anybody who doesn't know about it already: I've been
  using testnet-in-a-box (thanks Mike!) very successfully for testing. It
  gives you a nice, well-defined, controlled environment for reproducing
  bugs. Get it from: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0980}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-05 19:10:54 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12156.msg171864@s{hash}msg171864
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm optimistic about bitcoin because of two metrics: @p{»»}

    @p{(li} 1. Lots of people are interested in it, all over the world.
    @p{li)}

    @p{(li} 2. There are lots of interesting, innovative projects being
    built around bitcoin. @p{li)}

  @p{««}It is still VERY early days, and I'll say it again: expect growing
  pains. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0981}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-05 19:20:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12262.msg171902@s{hash}msg171902
@section 3 {tx}

  @s{quotedtext}

  @p{««}If I worked at AMD, I'd suggest that. @p{»»}

  @p{««}I started my professional career at SGI, writing 3D graphics demos
  and benchmarks, some of which were used to "burn in" the new hardware.
  Running a bitcoin miner along with a couple graphics demos (to exercise
  all the graphics hardware) might be a good way for ATI to make money on
  their burn-in process. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0982}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-05 19:36:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12156.msg171957@s{hash}msg171957
@section 3 {tx}

  @s{quotedtext}

  @p{««} Technical growing pains like the ones we're dealing with right
  now@p{--} IRC channel filling up so new people are having trouble
  connecting, BTC/$ going up so the 0.01BTC transaction fees are too high,
  etc. There will be more of these as transaction volume increases, some
  in the core bitcoin code and more affecting bitcoin-running websites
  (who will find they have to upgrade their servers to handle increased
  volume/users, etc). @p{»»}

  @p{««}Legal growing pains. I expect somebody doing something illegal and
  using bitcoins to help do it will get caught, put in jail, and that will
  be mis-reported as "bitcoins are illegal!" I'd say there's a 1 in 5
  chance of bitcoin being made outright illegal in the USA, but I also
  know that I'm terrible at accurately predicting stuff. @p{»»}

  @p{««}Security growing pains. My biggest worry is what to do about
  non-technologically-savvy people running bitcoin on a virus-infested
  personal computer or mobile phone and losing all their bitcoins the
  first time they enter their password (I'm assuming their wallet will be
  password-protected) to send a couple coins to their friend. @p{»»}

  @p{««}And just plain new-technology growing pains. Expect some (maybe
  most) bitcoin-related companies to fail, because most startups fail.
  Some people will lose money when they do. @p{»»}

  @p{««}Again, I'm optimistic because there are, and will be, lots of
  motivated people working to solve all of these problems, and because I
  believe the core technology is solid. But I don't expect smooth sailing.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0983}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-05 21:52:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12258.msg172485@s{hash}msg172485
@section 3 {tx}

  @p{««}The current plan is to password-protect private keys in the wallet
  and unlock them when coins are sent (with an option to 'remember the
  password' for a certain period of time) for the 0.4 release. @p{»»}

  @p{««}That doesn't completely fix the problem (a keystroke logger can get
  your password, and a virus can insert itself so instead of sending 10
  BTC to your grandma in Boise it makes bitcoin send your entire wallet
  balance to Little Bobby Blackhat). @p{»»}

  @p{««}To almost completely fix the problem transactions would need to be
  created on one device and then verified on a second device. Assuming
  both devices aren't infected/compromised, that will be safe. The two
  devices would be your computer and something else@p{--} maybe a website,
  If anybody has experience with that type of cross-device
  security/programming and is interested in helping Bitcoin out, help
  would be much appreciated. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0984}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-05 22:09:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12358.msg172530@s{hash}msg172530
@section 3 {tx}

  @p{««}Start here for possible holes: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms0985}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 01:22:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12317.msg173072@s{hash}msg173072
@section 3 {tx}

  @p{««}It costs the bitcoin network @p{(link}something like 0.001 US cents
  to process a typical transaction@p{link)}, so transactions less than
  about a cent don't make sense. @p{»»}

  @p{««}RE: using market forces for transaction fees: I agree 100%. But
  that code has to be written and thoroughly tested. The hard part is
  figuring out how miners communicate their "fee schedules" to clients
  (you can't just ask miners "what's your fee schedule" because they have
  an incentive to lie to try to get higher fees...). @p{»»}

  @p{««}So in the very short term fees are being dropped from 0.01 BTC per
  kilobyte to 0.0005 BTC per kilobyte. @p{»»}

  @p{««}I'll say it again: expect more growing pains like this. There will
  be more of them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0986}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 01:33:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7749.msg173103@s{hash}msg173103
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, because you're probably not directly connected to those pools,
  and the nodes you are connected to will drop transactions if they don't
  include the 'right' fee. @p{»»}

  @s{quotedtext}

  @p{««}Bitcoin already supports showing and sending less-than-0.01 BTC
  amounts. It is just smart and only shows 2 decimal places instead of
  always showing lots of extra zeroes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0987}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 01:57:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12343.msg173167@s{hash}msg173167
@section 3 {tx}

  @p{««}RE: Fee sheet: won't work, miners will lie to get higher fees.
  @p{»»}

  @p{««}RE: analyzing previous blocks to determine fees: I think it could
  work. Keeping track of how long transactions take to get into a block
  and looking at what transactions are in past blocks would, I think, work
  pretty well. Until/unless the criteria for including transactions gets
  really complicated. And new clients that haven't seen many transactions
  (and so can't tell how long prior transactions had to wait before being
  included in a block) might be an issue. @p{»»}

  @p{««}When we have multiple client implementations one of the ways I
  imagine they'll compete is to have smarter calculate-the-optimal-fee
  algorithms ("Use SpiffyBits(tm) and pay 2% lower transaction fees than
  the original bitcoin client!"). @p{»»}

  @p{««}RE: hashcash for transactions: that is exactly equivalent to fees
  (because you could be hashing to earn block rewards instead of hashing
  to get your transactions accepted). @p{»»}

  @p{««}RE: limiting number of small/free transactions that can go through
  a node in a given timespan: we're already doing that. @p{»»}

  @p{««}RE: canceling transactions: are there really people who would
  rather have their transaction tied up for half a day because they don't
  want to pay a half-a-penny fee? @p{»»}

  @p{««}RE: randomly dropping low-priority txns: interesting idea. I've
  been thinking that dropping the connection to a peer that is sending you
  "too many" low-priority transactions might be a good idea (where "too
  many" is maybe N standard deviations away from the number your average
  peer is sending you... or something....) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0988}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 02:06:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12343.msg173184@s{hash}msg173184
@section 3 {tx}

  @s{quotedtext}

  @p{««}Well... they COULD get punished for failing to relay. Just drop/ban
  them if they're not sending you "enough" valid transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0989}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 02:11:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12440.msg173189@s{hash}msg173189
@section 3 {tx}

  @p{««}First, don't sudo; there is no reason for bitcoin to run as root.
  @p{»»}

  @p{««}Second: it isn't done downloading the block chain. I just checked a
  bitcoind I've got running on an Amazon micro instance, and it is using
  less than 1% of the CPU. After you've got all 128,909 blocks the CPU
  usage should drop. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0990}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 11:25:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12336.msg174440@s{hash}msg174440
@section 3 {tx}

  @p{««}My mistake; I didn't test some new code thoroughly enough. Fixed
  now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0991}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 11:35:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12456.msg174458@s{hash}msg174458
@section 3 {tx}

  @p{««}Ian: @p{»»}

  @p{««}Great letter! I agree that the "stop campaigning for bitcoin's
  destruction" message might backfire, and the message should be "we're an
  innocent bystander here." You might even offer to help law enforcement
  better understand bitcoin so they can develop tools and techniques to
  catch criminals who use it. @p{»»}

  @p{««} I've been thinking of how to react to this story, and am tempted
  to appeal to people's greed/fear with a message of "your country may
  miss out on a huge new opportunity and be left behind if you try to
  stamp out innovative new technologies like bitcoin." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0992}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 14:07:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12604.msg174867@s{hash}msg174867
@section 3 {tx}

  @s{quotedtext}

  @p{««} Really? The testnet faucet didn't get them. @p{»»}

  @p{««}By the way: what's going on with the testnet? Is/was somebody
  playing around with "I've got more than 50% of the hashing power"
  attacks?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0993}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 14:55:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12456.msg175031@s{hash}msg175031
@section 3 {tx}

  @s{quotedtext}

  @p{««}Exactly right. I will to do what I can to help the police catch
  scammers and crooks who want to steal from people. The police might use
  those same tools and techniques to help catch people who use bitcoin to
  pay for drugs; I can't stop them from doing that. @p{»»}

  @p{««}I personally don't think drugs or gambling should be illegal,
  because I believe you should be free to do whatever you like with your
  own body and your own money. But I also believe those are separate
  issues from bitcoin, and if I felt really strongly about it (it isn't
  one of my own personal hot-button issues) I would be donating money to,
  or volunteering to work for LEAP and NORML, not mixing "bitcoin is a
  great new technology" with "drugs should be legal." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0994}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 18:06:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12456.msg175761@s{hash}msg175761
@section 3 {tx}

  @p{««}I wrote a blog post about this: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms0995}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 18:28:14 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12645.msg175852@s{hash}msg175852
@section 3 {tx}

  @p{««}If it is any consolation, I made the same mistake a few days ago
  (and am still waiting for the 25 BTC to appear in my account...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0996}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-06 22:34:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12577.msg176894@s{hash}msg176894
@section 3 {tx}

  @s{quotedtext}

  @p{««}Really? I've been encouraging alternative implementations, who is
  the power-hungry core developer? @p{»»}

  @s{quotedtext}

  @p{««}Ok. Start here: @s{(link)} @p{brk} Or here: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0997}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-07 12:11:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12970.msg179317@s{hash}msg179317
@section 3 {tx}

  @s{quotedtext}

  @p{««} 40 cents per visitor is definitely too much; I've set the Faucet
  to "down for maintenance" again, and will keep it that way until two
  things happen: @p{»»}

    @p{(li} 1. I change the amount awarded. @p{li)}

    @p{(li}and @p{li)} 2. bitcoin version 0.3.23 is released with lowered
  fees, so people can actually SPEND the bitcoins they get from the
  faucet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0998}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-07 12:24:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12964.msg179364@s{hash}msg179364
@section 3 {tx}

  @p{««}If you're worried about a "fund account with tiny bitcoins" attack,
  you should charge users that fund accounts with gazillions of tiny
  transactions an "excess account activity fee." I've been thinking about
  writing code for ClearCoin that does that, but at least so far it
  doesn't make sense for me to spend time doing that. @p{»»}

  @p{««}And see: @s{(link)} for the current thinking on how to handle fees
  at sending time. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms0999}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-07 12:47:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12935.msg179439@s{hash}msg179439
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, they're always mixed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1000}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-08 00:29:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13234.msg182322@s{hash}msg182322
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, there's no way. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1001}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-08 02:13:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12912.msg182685@s{hash}msg182685
@section 3 {tx}

  @p{««}Buying lots of bitcoins with dollars, driving the price up (and
  maybe creating an expectations bubble), then waiting for the price to
  stabilize before selling all you've bought (hoping to create panic
  selling) would, in my humble opinion, be an effective attack by anybody
  who had a lot of money to spend, didn't mind making the owners of the
  bitcoin exchanges very wealthy, and wanted to create fear, uncertainty,
  and doubt in the bitcoin market. @p{»»}

  @p{««}Of course, if there was somebody with a lot of bitcoins willing to
  sell on the way up and buy on the way down to stabilize prices... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1002}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-08 23:46:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13550.msg187898@s{hash}msg187898
@section 3 {tx}

  @p{««}I think I meant to post my version and just got busy and forgot...
  @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1003}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-09 12:11:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12817.msg190290@s{hash}msg190290
@section 3 {tx}

  @p{««}I'm going to keep the main Faucet closed until the 0.3.23 client
  with default 0.0005 fees are in place, and I'll drop the reward to
  somewhere around 1 millibitcoin (which, at $30/BTC, is 3 cents). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1004}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-09 12:12:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13941.msg190295@s{hash}msg190295
@section 3 {tx}

  @p{««}Can you make one that says "I am NOT Satoshi Nakamoto" ?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1005}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-09 15:32:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=363.msg191092@s{hash}msg191092
@section 3 {tx}

  @p{««}Testnet faucet is up and running if you need testnet coins: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Although I've mostly been using testnet-in-a-box for testing
  recently: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1006}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-10 03:55:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13837.msg194390@s{hash}msg194390
@section 3 {tx}

  @p{««}See @p{(link}@s{(link)}(JSON-RPC@p{link)}) for relevant advice.
  @p{»»}

  @p{««}As Pieter says, bitcoin converts all user-entered values and
  JSON-RPC values to fixed-point 64-bit integers as soon as it gets them.
  All calculations except for that conversion are done using 64-bit
  integers. @p{»»}

  @p{««}Bitcoin does not "use floating point", it parses
  numbers-containing-a-decimal-point values that come from JSON (the
  Number type in JSON is double-precision float; let's not restart the "we
  should pass numbers as strings in JSON" debate, please, there are
  several long threads from a couple of months ago about that) or from the
  GUI. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1007}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-10 04:20:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13469.msg194456@s{hash}msg194456
@section 3 {tx}

  @p{««}I'll confess: the bitcoin GUI is not a high development priority
  for me because I think downloading and running software on your computer
  will soon be almost extinct. @p{»»}

  @p{««}I expect pretty soon most people will be using bitcoin through web
  applications (like mybitcoin or instawallet) or as apps running on their
  mobile phones. @p{»»}

  @p{««}I'll also confess that I like the bittorrent model@p{--} create a
  great technology, a "good enough" interface for it, and encourage the
  creation of compatible applications that have great user interfaces.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1008}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-10 23:00:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12456.msg198783@s{hash}msg198783
@section 3 {tx}

  @p{««}Does anybody have the full text of the open letter? Mr. Google is
  failing me when I search for it... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1009}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-10 23:04:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=13418.msg198802@s{hash}msg198802
@section 3 {tx}

  @s{quotedtext}

  @p{««}I still think selling boot-able USB sticks that contain a Linux
  distro, bitcoin, a bitcoin miner, and "starter" bitcoins would be a
  great eBay business/product. You're not selling currency, you're selling
  software and a USB stick. @p{»»}

  @p{««}You'll have to have a good eBay rep, though, because the person who
  gets it would have to trust that you didn't keep a copy of the wallet.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1010}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-11 01:06:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=14786.msg199252@s{hash}msg199252
@section 3 {tx}

  @p{««}This would be like a 6-blocks-back block chain lock-in. Maybe not a
  bad idea at this point (unlike the early days when legitimate users
  might throw lots of new hashing power at the network or there might have
  been network splits because there were so few nodes). @p{»»}

  @p{««}I think there would have to be an override, in case there WAS an
  hour or two or three network split. @p{»»}

  @p{««}Or maybe some attempt to detect double-spends (e.g.
  more-than-5-block-split OK if all transactions are valid on both
  chains). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1011}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-11 05:11:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=12577.msg199969@s{hash}msg199969
@section 3 {tx}

  @p{««}Busy... very busy... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1012}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-11 14:55:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=15044.msg201165@s{hash}msg201165
@section 3 {tx}

  @p{««}I'm reposting from the ClearCoin news blog: @p{»»}

    @p{(li} @s{(link)} @p{li)}

  @p{««}I've been contacted by a charity who is not happy that they were
  listed as a donation option for ClearCoin charity escrows. @p{»»}

  @p{««}I made the mistake of assuming that charities would appreciate the
  extra bitcoins; it never occurred to me that ClearCoin customers might
  contact a charity and ask THEM for their (supposedly-donated) coins
  back. Charities can't be expected to resolve ClearCoin disputes. @p{»»}

  @p{««}To fix the problem, I have disabled all charities for new escrow
  accounts except one: the Bitcoin Faucet. I will be writing to any
  charities that received ClearCoin donations from already-created escrow
  transactions to make them aware of the situation and will ask them to
  forward any ClearCoin-related issues to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1013}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-12 13:19:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=14693.msg207603@s{hash}msg207603
@section 3 {tx}

  @p{««}I exchanged email with Jacob, and he's predicting bugs because some
  very good "white-hat" people are looking hard at the code, trying to
  find bugs or vulnerabilities. @p{»»}

  @p{««}That's all. And that's good news; the more people who try to find
  problems with the code (and who will report any problems responsibly so
  they can get fixed before they're exploited), the better. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1014}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-12 13:38:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=15787.msg207683@s{hash}msg207683
@section 3 {tx}

  @p{««}Yep. Every transaction you make potentially leaks a little
  information about other transactions to/from your bitcoin wallet. @p{»»}

  @p{««}That's why I always say "bitcoin anonymity is complicated" and
  "bitcoin transactions are more private than credit card or bank
  transactions, but less private than cash transactions" or "staying
  completely anonymous while using bitcoins is hard." @p{»»}

  @p{««}And that's why you won't find (or, at least, shouldn't find) any
  claims that bitcoin is anonymous on the bitcoin.org home page or in the
  bitcoin source code. @p{»»}

  @p{««}What can you do? Use separate wallets. Make your donation address
  an instawallet or mybitcoin address that you don't use for anything
  else. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1015}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-12 22:01:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=15527.msg209897@s{hash}msg209897
@section 3 {tx}

  @s{quotedtext}

  @p{««}As long as the questions are core-bitcoin-related and not specific
  to your alternative client. @p{»»}

  @p{««}Good alternative client question: "I'm writing an alternative
  client that doesn't store private keys at all (they are generated from
  the user's password). But I'll need a bitcoin protocol message that does
  XYZ to make it work; are other clients willing to support that new
  message?" @p{»»}

  @p{««}Bad alternative client question: "I'm coding my alternative client
  in Forth; what's the best GUI toolkit to use?" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1016}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-13 16:09:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=16335.msg213157@s{hash}msg213157
@section 3 {tx}

  @p{««}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1017}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-17 12:42:54 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=18238.msg232113@s{hash}msg232113
@section 3 {tx}

  @p{««}If your device (computer, mobile phone) is infected and your
  bitcoin wallet keys are stored on that device (encrypted or not), then
  the bad guys will get your coins sooner or later. @p{»»}

  @p{««}Sooner if the wallet is not encrypted. Later if it is encrypted.
  @p{»»}

  @p{««}Come up with all the fancy "measure timing and enter your
  fingerprints and choose an 80-character-long password and store your
  private keys inside the Trusted Platform Module Chip" pseudo-security
  measures you like; if your device is infected they will not work. @p{»»}

  @p{««}The bad guys will simply hack the software so that you THINK you're
  securely sending 1 bitcoin to your cousin (because that's what it says
  on the screen), but instead you're REALLY authorizing sending your
  entire bitcoin balance to the bad guys. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1018}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-18 12:28:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=18514.msg237590@s{hash}msg237590
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}If you can, please help test, it really helps. Patch for wallet
  encryption is at: @s{(link)} @p{brk} As bitlotto says, us a wallet with
  very few coins in it and/or run with the -testnet flag to use test
  network coins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1019}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-18 14:33:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=18877.msg237969@s{hash}msg237969
@section 3 {tx}

  @p{««}Bitcoin's technology is unstoppable, like p2p filesharing has
  proven to be unstoppable. But "the Bitcoin Project" could fail in a
  bunch of different ways. @p{»»}

  @p{««}If mainstream people think "Oh, bitcoin is that internet thing used
  by criminals", that is bad for bitcoin. It might be bad enough to kill
  the project (note that I said "the project", not "the technology").
  @p{»»}

  @p{««}If bitcoin really does turn into an internet thing only used by
  criminals then I'll personally consider it a failed experiment and will
  find something else to do. @p{»»}

  @p{««} PS: the cbsnews interview was with Jeff, not me, and my last name
  is "Andresen" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1020}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-18 17:10:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=18997.msg238574@s{hash}msg238574
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1021}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-18 19:07:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg239156@s{hash}msg239156
@section 3 {tx}

  @p{««}So I've been thinking a lot about wallet security; Matt's password
  patch is a good first step, but maybe we can at least build in some
  infrastructure for a better solution. @p{»»}

  @p{««}We really need a solution where transactions are generated on one
  device and then verified on a second device, so malware must compromise
  both devices (e.g. computer and mobile phone, or web wallet and mobile
  phone) to steal coins. @p{»»}

  @p{««}gmaxwell from IRC thinks it can be done without multiple signatures
  (just with the standard transaction we have now), and staring at the
  ECDSA math @p{(link}on this wikipedia page@p{link)} I think he's right.
  I believe he was inspired by ByteCoin's observation that you can create
  a vanity public key generating service that is secure@p{--} the service
  can generate the public key but not know the private key. @p{»»}

  @p{««}I'm mostly writing this to convince myself it could work and to
  give ByteCoin and Hal and gmaxwell and anybody else who knows a whole
  lot more crypto than me a chance to poke holes in it. And then point me
  to a FIPS standard that has it all figured out already... @p{»»}

  @p{««}So: generating an ECDSA keypair means choosing a private key d_(A),
  then calculating the public key Q_(A) = d_(A)G (where G is a fixed point
  on the elliptic curve). @p{»»}

  @p{««}The key generation can be split; have device 1 choose d_(A1) and
  device 2 choose d_(A2). Device 1 then sends Q_(A1) to Device 2, and it
  can calculate Q_(A1)d_(A2) = Q_(A1*A2). Or in english, Device 1 finds a
  public key on the curve. Then Device 2 uses its part of the private key
  to do a bunch more elliptic curve multiplies to find the composite
  public key without ever knowing Device 1's public key. @p{»»}

  @p{««}So great, neither Device 1 or 2 needs to ever have both parts of
  the private key on them to generate the shared public key. @p{»»}

  @p{««}Now lets say Device 1 wants to spend a TxOut that is one of these
  split keys. The key bit of the signature generation algorithm (see the
  Wikipedia page:
  @p{(link}@s{(link)}@s{hash}Signature_generation_algorithm@p{link)} ) is:
  @p{brk} ... @p{brk} 4. Calculate s = k^(-1)(z+rd_(A))(mod n) @p{brk} ...
  @p{brk} That can be rewritten as: @p{»»}

  @p{««}Calculate s = k^(-1)(z+rd_(A1)d_(A2))(mod n) @p{»»}

  @p{««}And now I'm stuck. Can that equation be refactored so that Device 1
  can compute part of the signature, send its partial result to Device 2,
  and have Device 2 complete the signature (without Device 2 being able to
  figure out 1's part of the private key?)? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1022}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-18 23:22:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19154.msg240243@s{hash}msg240243
@section 3 {tx}

  @p{««}Planet Money is one of my favorite podcasts. @p{»»}

  @p{««}They interviewed me when I was in France, and I hope I didn't say
  anything too stupid. They seemed "appropriately skeptical." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1023}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-19 16:08:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg243379@s{hash}msg243379
@section 3 {tx}

  @p{««}FYI: I posted this here on the forums because I see the mailing
  list as being for nuts-and-bolts "lets talk about exactly how to get XYZ
  done." @p{»»}

  @p{««}And I see these forums as a better place for brainstorming and
  pie-in-the-sky maybe-it-will-work-maybe-it-won't discussions. @p{»»}

  @p{««}Also, equations don't look pretty in plain-text emails. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1024}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-19 20:49:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg245253@s{hash}msg245253
@section 3 {tx}

  @p{««}I'm busy watching the Red Sox whoop the Brewers. @p{»»}

  @p{««}I'm planning on posting my talk's slides tomorrow. I gave a general
  report on the visit on Bruce's Bitcoin Show.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1025}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-19 22:36:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19667.msg246139@s{hash}msg246139
@section 3 {tx}

  @p{««}Yes, don't trust me, please. I am human and will make mistakes.
  @p{»»}

  @p{««}The CSRF vulnerability on ClearCoin is fixed. I will be contacting
  any ClearCoin customers who have changed their refund addresses to make
  sure that they were not the victim of a CSRF attack. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1026}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 00:23:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg246792@s{hash}msg246792
@section 3 {tx}

  @s{quotedtext}

  @p{««}Because sending to a multiple-signature-required address requires a
  new standard transaction type, a new type of bitcoin address, and a
  protocol for Device 1 @p{lt}-@s{gt} Device 2 communication. More code
  means more possibility of bugs, so I was hoping there is a simpler
  solution. @p{»»}

  @p{««}And as I said in the original post, I wanted to start discussion:
  @s{quotedtext}

  @p{««}If the answer is "multiple signatures" then so be it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1027}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 01:39:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19168.msg247205@s{hash}msg247205
@section 3 {tx}

  @s{quotedtext}

  @p{««}I agree; I think allowing commas in numbers is a bitcoin GUI
  mis-feature. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1028}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 12:35:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8728.msg249860@s{hash}msg249860
@section 3 {tx}

  @p{««}RE: making it harder to brute-force: @p{»»}

  @p{««}I have a couple of thoughts. First, if users choose passwords like
  'abc123' or 'password' or any of the other top-1,000 passwords it
  doesn't matter if we're scrypt'ing; they're toast. I'd rather see work
  on either giving users feedback on how strong or weak their password is
  rather than adding a tiny-little-bit-more security by scrypting. @p{»»}

  @p{««}That said, changing the 'ekey' data so that ONLY the 256-bit
  private key is encrypted should increase security with very little extra
  code. Consider what you'd have to do to brute-force: @p{»»}

  @p{««}1000 x SHA256(password_text) @p{»»}

  @p{««}Now you have a 256-bit number. Is it the right private key? To
  check: @p{brk} ECC multiply to get candidate public key @p{brk}
  RIPEMD160(SHA256(candidate public key)), and check to see if it matches
  public key. @p{»»}

  @p{««}Anybody know how easy it is to GPU parallelize ECC multiplies? A
  quick google search gives me the impression that is an area of active
  research. @p{»»}

  @p{««} RE: pre-computing wallet keys: @s{huh}?? wallet private keys are
  256-bit random numbers. Am I misunderstanding you gmaxwell? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1029}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 12:48:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg249907@s{hash}msg249907
@section 3 {tx}

  @p{««}RE: pulling the wallet private key encryption ASAP: Agreed 100%
  @p{»»}

  @p{««}I wanted to start discussing split keys now because if we need a
  new standard transaction type then it is best to do that in stages@p{--}
  let clients relay, and miners include in blocks, the new transaction
  type. Then once most of the network will accept the new transactions,
  people can actually start USING them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1030}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 18:48:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6652.msg251755@s{hash}msg251755
@section 3 {tx}

  @p{««}I just uploaded pdf and KeyNote versions of the talk I gave at the
   CIA last Tuesday: @p{brk} @s{(link)} @p{brk} @s{(link)} @p{»»}

  @p{««}I took questions in the middle, before I dove into the technical
  details. I was asked about whether or not I thought price instability
  would be a problem ("yes, I'll talk about that later") and how/why I got
  involved. @p{»»}

  @p{««}Later, at the panel discussion, I was asked a question that showed
  I need to do a better job of distinguishing bitcoin addresses and IP
  addresses. And I was asked if there were moral issues, since bitcoin can
  be used by criminals ("I'm working on bitcoin because I think the
  potential benefits to the world are much, much greater than the costs.")
  @p{»»}

  @p{««}The other speakers were from PayPal, Facebook Payments, M-Pesa,
  Heartland Payment Systems, and the Federal Reserve, so it was worth
  going just for the connections. Bitcoin is definitely the new kid on the
  block, and I presented it as such; not "bitcoin will take over the
  world" but "bitcoin is a very interesting experiment that could be
  world-changing if it works out." @p{»»}

  @p{««}And now... there is plenty of work to be done, so I'm going to stop
  reminiscing about the good old days last week....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1031}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-20 20:38:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20185.msg252472@s{hash}msg252472
@section 3 {tx}

  @p{««}Cindy Cohn, legal director at the EFF, called me a while ago to
  figure out what to do with the bitcoin donations they were sent, and
  what to do with coins that might be sent to their donation address in
  the future. @p{»»}

  @p{««}Ideally, they'd like to return them, but that can't be done@p{--}
  bitcoin has no "return to sender" function. Returning to the
  last-address-the-coins-were-sent-to doesn't work because people use
  shared online wallets and can, and do, send their coins to new wallets
  and delete old wallets. @p{»»}

  @p{««}The EFF is firm in their decision NOT to cash them in (they'll be
  coming out with a blog post explaining their reasons very soon), and
  after talking over several possibilities the idea they liked best was to
  redistribute the coins via the Bitcoin Faucet (and have any donations
  that trickle in get passed back out via the Faucet). The reasoning is
  that anybody who donated bitcoins to the EFF would also support the
  mission of the Faucet@p{--} to promote bitcoin by giving people new to
  the currency a little bit to start. @p{»»}

  @p{««}Other options for what to do with the EFF donations (like setting
  up a non-profit entity to take the donations and... do something with
  them...) were rejected as too complicated and/or costly. @p{»»}

  @p{««}I'll need to do a little bit of thinking about how to handle the
  EFF coins safely (just dumping them all into the Faucet's wallet is not
  a good idea; I would hate for them to get lost if somebody managed to
  hack the Faucet's web-facing code). Whatever I do, I will make sure the
  process of moving the coins from the EFF's donation address to the
  Faucet is absolutely transparent. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1032}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-21 02:48:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20185.msg254716@s{hash}msg254716
@section 3 {tx}

  @p{««}EFF blog post: @s{(link)} @p{»»}

  @p{««}RE: refunding donations by proving you own one of the private keys
  that donated: interesting idea! Anybody willing to write code to do
  that? Could be a fun project... (find all the transactions that donated
  to EFF, dig out the public keys, come up with a way to sign/verify a
  message with private key proving you own a public key, then keep track
  of which donation transactions have already been refunded) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1033}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-21 14:06:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg257614@s{hash}msg257614
@section 3 {tx}

  @s{quotedtext}

  @p{««}Zero-knowledge proofs... ummm.... @p{»»}

  @p{««}Nice to know it @p{(it}can@p{it)} be done securely. I'll leave it
  to the professionals to actually do it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1034}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-21 20:27:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5961.msg259772@s{hash}msg259772
@section 3 {tx}

  @p{««}Anybody else already working on tests? @p{»»}

  @p{««}Steve: mind if I pull out just the boost-unit-test bits of your
  tree? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1035}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-22 13:36:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8153.msg264113@s{hash}msg264113
@section 3 {tx}

  @p{««}I don't want to keep putting band-aids on the transaction fee
  problem, so I'm against adding Yet Another Button to the client. @p{»»}

  @p{««}If you're impatient and can't stand the thought of paying
  half-a-millibitcoin for a transaction, then compile your own version of
  bitcoin. Just don't complain if you end up with a wallet full of
  0/unconfirmed transactions that tie up all your funds. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1036}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-22 19:43:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg265907@s{hash}msg265907
@section 3 {tx}

  @p{««}The risk profile I care about is: @p{»»}

  @p{««}User's computer is completely compromised by a root-kit trojan, but
  they don't know it. @p{»»}

  @p{««}However, the user has access to some other device or service that
  they have setup in advance to be a "second line of defense" to prevent
  their entire wallet from being stolen.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1037}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-23 00:39:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=7421.msg267313@s{hash}msg267313
@section 3 {tx}

  @p{««}I took error's work and further tweaked so it works (and is rebased
  against) latest git head. @p{»»}

  @p{««}... but I'm not 100% happy with it. I'm not sure it properly
  handles block chain re-orgs and dependent orphan transactions. Would be
  nice to write some tests to exercise those edge cases, and figure out
  what it SHOULD do in those cases. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1038}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-23 01:09:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg267432@s{hash}msg267432
@section 3 {tx}

  @p{««}Here's a use case I'd like to work: @p{»»}

  @p{««}I tell Bitcoin running on my computer or cell phone to run
  transactions through a bitcoin security service@p{--} maybe I give it a
  @s{(link)} URL for the service. @p{»»}

  @p{««}I tell the security service "auto-approve small-value transactions,
  but give me a call for any transactions above $X (or $XY per day)."
  @p{»»}

  @p{««}The security service sends me something in the mail that I keep
  safe, but that I can use to recover use of my bitcoins in case the
  security service goes out of business or disappears or I decide to stop
  paying for the service. @p{»»}

  @p{««}I get bitcoin addresses either from my bitcoin client (not
  trustworthy!) and/or from the security service that require both my
  computer and the security service to sign to spend. And I have people
  send bitcoins (or I self-send my own bitcoins) to those addresses. @p{»»}

  @p{««}Spending coins is done as usual@p{--} I type in an amount and an
  address. Behind the scenes, magic happens, and if the transaction is
  greater than $X I get a phone call @p{--} "Press 1 to confirm payment of
  $X bitcoins to bitcoin address blah, press 2 to cancel." @p{»»}

  @p{««}If I suddenly get random phone calls, I know my computer has been
  infected. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1039}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-23 17:47:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19080.msg271176@s{hash}msg271176
@section 3 {tx}

  @p{««}RE: cryptocards instead of an online service: @p{»»}

  @p{««}Seems like we aught to be able to come up with a protocol that
  works over the web or that can talk to @s{(link)} to interact with an
  attached smart-card device (there'd be helper software running on
  localhost:SOMEPORT that spoke the protocol and relayed to the smart
  card). @p{»»}

  @p{««}I wanted to start this discussion to make sure we don't re-invent
  the wheel, and to think in advance about what changes to core bitcoin
  (if any) are needed to support this kinds of functionality. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1040}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-23 21:29:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=21659.msg272243@s{hash}msg272243
@section 3 {tx}

  @p{««}I've been struggling recently to keep ClearCoin moving forward
  while I also try to keep core bitcoin on track, and with all the demands
  on my time I can't spend the time on ClearCoin to make it a project that
  I'm really proud of. @p{»»}

  @p{««}So in the next day or two I'll stop allowing the creation of new
  escrow transactions. Existing transactions will be unaffected, and I'll
  keep ClearCoin running for at least two months after the last active
  transaction has expired. @p{»»}

  @p{««}I hope ClearCoin will be back at some point in the future, but I
  won't bring it back until a lot of behind-the-scenes work is done to
  make it a robust, scalable business.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1041}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-25 00:00:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=21983.msg278642@s{hash}msg278642
@section 3 {tx}

  @p{««}Facebook credits are designed so that dollars go in, but only flow
  back out to the companies with facebook games. @p{»»}

  @p{««}And Facebook tries hard to ensure that the companies cashing out
  the credits are real companies, and not people just trying to move money
  through their system. There are no open exchanges, by design. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1042}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-27 15:07:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=22434.msg292229@s{hash}msg292229
@section 3 {tx}

  @p{««}A long-term fix for transaction fees (as opposed to the ad-hoc
  "we'll just try to guess what the 'right' fees are") is high on my
  priority list for bitcoin. There are only two very-high-priority things
  on my bitcoin wish list: fix scaling issues and make sure we have any
  infrastructure in place to support ultra-high-security wallets. Fixing
  transaction fees is a scaling issue. @p{»»}

  @p{««}"Pick a fee and hope my transaction makes it into a block" is
  @p{(bf}NOT@p{bf)} the right answer. And we've already seen what happens
  when there is a mismatch between miner transaction fee policies and
  client transaction fees (remember the big backlog of low-priority
  transactions we had a couple of months ago?). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1043}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-28 12:24:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=23266.msg296706@s{hash}msg296706
@section 3 {tx}

  @p{««}I'd like to see somebody work on a "shun ill-behaved peers" patch.
  @p{»»}

  @p{««}So if one of your peers sends you lots of garbage
  (blocks/transactions/addresses/whatever) you just disconnect from it and
  refuse to accept connections from it for a while. @p{»»}

  @p{««}The trick is thinking really hard about what is really 'garbage'
  and what might be honest, it-happens-every-so-often weird behavior due
  to block chain splits or other network events. @p{»»}

  @p{««}The goal would be to prevent a wide range of denial-of-service
  attacks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1044}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-29 14:44:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=17921.msg302239@s{hash}msg302239
@section 3 {tx}

  @p{««}I moved this from the Newbie forum@p{--} looks like a great
  project! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1045}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-29 18:22:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24414.msg303070@s{hash}msg303070
@section 3 {tx}

  @p{««}Wow, this snuck up on me... @p{»»}

  @p{««}So I'm headed to Australia in a week. I'll be in Sydney for a few
  days; anybody want to meet for lunch on the 9'th or 10'th? @p{»»}

  @p{««}Then I'll be in Hobart for a couple of weeks, then near Cairns for
  a couple of week beginning July 22'nd; send me an email if you're
  nearby.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1046}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-29 18:45:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24422.msg303152@s{hash}msg303152
@section 3 {tx}

  @p{««}One of Bitcoin's major challenges is the legal uncertainty
  surrounding it. @p{»»}

  @p{««}It is really no different from other new Internet technologies
  (should Skype be regulated like a phone company? Does google's
  deep-linking violate copyright? ... to give two examples from a few
  years ago...), but because it is money there are a lot more laws and
  regulations that may or may not apply. @p{»»}

  @p{««}It'd be easy to ignore that and just damn the torpedoes, full steam
  ahead with the technology. And given the nature of geeks on the
  Internet, that is what is going to happen anyway... but I decided it
  wouldn't hurt to try to be proactive and start a conversation with my
  representatives in Washington, DC about the Bitcoin Project. @p{»»}

  @p{««}So I met briefly with staffers from Rep. Olver and Sen. Brown's
  offices yesterday. I gave a very brief overview of bitcoin, mentioned
  Senator Schumer's "eradicate Silk Road" press conference, and stressed
  that Bitcoin is meant to be a stable, secure, international currency for
  the Internet, NOT a currency for criminals. @p{»»}

  @p{««}I also mentioned that the legal uncertainty is a barrier to
  innovation, and asked for advice on what, if anything, could be done
  about that. There is no good answer@p{--} government moves really
  slowly, and they're wedging newfangled Internet ideas into legal
  structures that were created when telephone were the latest and greatest
  technology. @p{»»}

  @p{««}However, the house of representatives staffer I talked with did
  suggest that encouraging you-all to introduce yourselves to your
  congressperson's staff is a good idea. If they know that interesting,
  job-creating bitcoin businesses are happening in their districts and
  they've met the person making it happen, then they're @p{(bf}much@p{bf)}
  more likely to support bitcoin-friendly legislation. @p{»»}

  @p{««}So, if you're an upstanding, law-abiding, clear-thinking citizen
  doing interesting things with Bitcoin, I encourage you to take a little
  time and introduce yourself to your representative's staff. I wouldn't
  bother talking to the representative@p{--} they're probably too old to
  really understand bitcoin ("Tubes! Money through the tubes I say!").
  Talk to a 20-something staffer who grew up with the Internet and is
  likely to be a lot more sympathetic to the idea of a peer-to-peer
  Internet money. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1047}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-29 19:46:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=21983.msg303388@s{hash}msg303388
@section 3 {tx}

  @p{««}One of the speakers at the Emerging Technology conference I
  attended at the CIA was from Facebook Payments, and he seemed pretty
  adamant that they're committed to doing what they can to keep the people
  buy the credits (users who want to play games) separate from the people
  who cash them out (the game developers). @p{»»}

  @p{««}So a facebook app implementation of bitcoinjs would very likely not
  be approved for Facebook payments.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1048}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-29 23:12:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63.msg304216@s{hash}msg304216
@section 3 {tx}

  @p{««}bitcointools has a fixwallet.py that can often fix broken
  wallet.dat files. @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1049}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-06-30 23:11:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=21659.msg308737@s{hash}msg308737
@section 3 {tx}

  @s{quotedtext}

  @p{««}Several people have asked me about buying it, but I won't sell it
  unless I trust that the team that takes it on has experience keeping
  customer's money safe and the resources to do all of the things I don't
  have time for@p{--} penetration testing, better customer support,
  insurance on the coins in escrow, etc. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1050}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-01 14:41:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24813.msg311220@s{hash}msg311220
@section 3 {tx}

  @s{quotedtext}

  @p{««} Who decides whether or not a miner has broken the rules? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1051}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-04 13:51:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=19168.msg322524@s{hash}msg322524
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}I think this is critical enough to include in 0.3.24rc2. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1052}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-04 20:59:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=25988.msg324178@s{hash}msg324178
@section 3 {tx}

  @s{quotedtext}

  @p{««} So go ahead and document it, volunteer to keep it up to date
  (that's the hard part), and submit a patch. After the latest source-file
  re-org, there is a top-level doc/ directory where a "wallet_format.txt"
  file would go. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1053}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-05 20:00:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5920.msg328468@s{hash}msg328468
@section 3 {tx}

  @p{««}Losing double-spent transactions should probably be reported as
  -1/unconfirmed, -2/unconfirmed, etc @p{--} meaning "there is a
  N-confirmed transaction that conflicts with this one." @p{»»}

  @p{««}-6/unconfirmed seems like the natural "this transaction ain't never
  gonna be confirmed, time to report it as -N/orphan." @p{»»}

  @p{««}-1/unconfirmed should be enough to stop re-transmitting it. @p{»»}

  @p{««}And -120/orphan seems like a safe time to "unspend" any inputs (let
  them be spent by new transactions) that weren't spent by the other,
  conflicting transaction. @p{»»}

  @p{««}... he says nonchalantly, knowing full well that actually making
  bitcoin behave that way means a lot of very careful coding and lots and
  lots of careful testing... @p{»»}

  @p{««}The shortcut, maybe-good-enough-for-now solution: export all the
  private keys from all the messed up wallets. Start with a clean wallet,
  then re-import all the private keys and let the clean-slate bitcoin
  figure it all out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1054}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-05 21:06:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=26327.msg328773@s{hash}msg328773
@section 3 {tx}

  @p{««}I'm thinking about how to do higher-level testing of bitcoin, and I
  think we could get a lot of mileage out of a testing harness that works
  at the network protocol level. @p{»»}

  @p{««}I'm thinking of testing things like proper handling of block chain
  re-orgs and valid and invalid transactions. @p{»»}

  @p{««}Examples: @p{»»}

  @p{««}@p{(bf}Block chain re-org test:@p{bf)} @p{»»}

    @p{(li}Start a bitcoin client with an empty wallet and just the
    genesis block, -noirc listening on a non-standard port.@p{li)}

    @p{(li}test harness connects, then feeds it a pre-canned block chain
    @p{li)}

    @p{(li} ... then sends it a longer fork@p{li)}

    @p{(li}test harness makes sure client accepted the longer chain by
    sending it a getblocks messsage @p{li)}

    @p{(li}(or disconnects and re-connects and checks the start_height in
  the version message) @p{li)} @p{li)}

  @p{««}@p{(bf}Valid/invalid transaction tests@p{bf)} @p{»»}

    @p{(li}Start bitcoin client as above@p{li)}

    @p{(li}test harness connects, sends a series of valid and invalid
    transactions (via inv message and then responding to getdata).@p{li)}

    @p{(li}test harness checks to see if transactions were accepted or
   rejected by checking responses to getdata (should be no response for
   invalid transactions)@p{li)} @p{»»}

  @p{««}@p{hrule} A set of good data files with "tx" and "block" (and "inv"
  and all the rest) messages in them, combined with something like
  @p{(link}pexpect@p{link)} could make a good test system. I'm thinking
  they should be human-readable (with a proxy listening tool or wireshark
  plugin or something that dumps bitcoin protocol into the human-readable
  form) but pretty low-level; maybe @p{(link}a version message@p{link)}
  looks like: @p{»»}

  @s{code}

  @p{««}So, before I start working on something like this: Anybody already
  doing something similar?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1055}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-13 11:28:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5909.msg358391@s{hash}msg358391
@section 3 {tx}

  @s{quotedtext}

  @p{««}It will get confirmed; it is already 'funded' (you can never send
  more coins than you have in total in your wallet). @p{»»}

  @p{««}This example might help; if you have exactly two accounts in your
  bitcoin wallet and their balances are: @p{»»}

  @p{««}Account A: -0.1 BTC @p{brk} Account B: 1 BTC @p{»»}

  @p{««}... then if you tried to send 1 btc from account B the send would
  fail with an "insufficient funds" error. @p{»»}

  @p{««}I'd suggest funding a 'TransactionFees' account, and then when a
  sendfrom results in transaction fees reimburse the account by moving
  funds from TransactionFees.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1056}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-13 11:37:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=28462.msg358407@s{hash}msg358407
@section 3 {tx}

  @p{««}Very-low-priority transactions @p{(bf}will@p{bf)} get dropped by
  peers, because they look like "spam" transactions and network bandwidth
  is not free. @p{»»}

  @p{««}I don't know if the current rules are written down anywhere besides
  the source code; improving the fee-handling and spam-detecting code in
  bitcoin is high on my bitcoin improvement wish-list, so if they were
  written down they'd be likely to change fairly soon... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1057}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-15 00:55:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24784.msg364599@s{hash}msg364599
@section 3 {tx}

  @p{««}Does this patch give any sort of warning if bitcoin isn't being
  used through a proxy? @p{»»}

  @p{««}I worry that a user will be REALLY careful keeping all their
  addresses separated so their ordinary transactions are separate from
  their fund-the-oppositition transactions, and then will get busted by
  the Secret Police who were eavesdropping on their bitcoin IP traffic at
  their ISP. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1058}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-15 07:02:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24784.msg365322@s{hash}msg365322
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because to non-technical users, "privacy" is a single feature, not
  a series of separate technical issues.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1059}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-15 23:51:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807.msg367985@s{hash}msg367985
@section 3 {tx}

  @p{««}Yes, all of the send* methods return a transaction id on successful
  send. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1060}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-17 03:45:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=29475.msg371573@s{hash}msg371573
@section 3 {tx}

  @s{quotedtext}

  @p{««} Don't do that, you'll just spend a lot of time re-downloading the
  block chain and then be back in the same state you were before (unless
  you happen to get lucky and your transactions get confirmed while you're
  waiting for the block chain to download again). @p{»»}

  @p{««}Restarting bitcoin and letting it get 8 fresh connections might
  help. Allowing incoming connections so you have more than 8 connections
  should also help your transactions get confirmed. @p{»»}

  @p{««}Safest thing to do is to be patient; your transactions will be
  rebroadcast and eventually will get confirmed. If they're not confirmed
  in a week, then there are ways of deleting the transactions from your
  wallet and "freeing up" the stuck bitcoins, but messing with your wallet
  should always be a last resort. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1061}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-17 12:05:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=27699.msg372412@s{hash}msg372412
@section 3 {tx}

  @p{««}Bitcoin 0.3.24 adds a -port= option to listen on a port other than
  8333 for incoming connections. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1062}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-18 00:30:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5011.msg374008@s{hash}msg374008
@section 3 {tx}

  @s{quotedtext}

  @p{««} Works for me (from a private testnet bitcoind): @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1063}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-20 11:14:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=30286.msg382440@s{hash}msg382440
@section 3 {tx}

  @p{««}The google link on the bitcoin.org homepage is/was my idea. @p{»»}

  @p{««}"The One True Forums" for bitcoin doesn't make sense to me@p{--}
  the whole point of bitcoin is to be decentralized. I sincerely believe
  that open and free competition makes everything better, and I hope that
  more places to discuss bitcoin pop up and compete to be the best. @p{»»}

  @p{««}In the future, I'd like most of the links on the bitcoin.org home
  page to be google searches, including the "download bitcoin" links (I
  think we'll see some great new bitcoin clients released over the next
  six months or so). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1064}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-20 11:34:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=30200.msg382485@s{hash}msg382485
@section 3 {tx}

  @p{««}I've been making slow but steady progress on my
  at-the-network-level testing tool. I don't put a lot of faith in
  standards documents@p{--} it is too easy to misinterpret or ignore them.
  Good implementation-independent test suites seem like a better
  investment of time. @p{»»}

  @p{««}What's working: python-based code that serializes/deserializes
  messages in both bitcoin's binary format (to talk to the node being
  tested) and JSON (so it is easy for us humans to tweak/examine test
  data). Connecting and requesting all blocks. @p{»»}

  @p{««}Still todo: actually start writing test cases, figure out what
  other tools I need to write to create good test cases, and start
  systematically going through the "rules of bitcoin" and devising tests
  to make sure the rules are being followed@p{--} starting with the
  super-important "get this wrong and you split the blockchain" rules.
  @p{»»}

  @p{««}I hope to recruit some of you to help out with all that... I'll be
  creating a github project with my progress so far very soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1065}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-25 00:32:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=30200.msg395833@s{hash}msg395833
@section 3 {tx}

  @p{««}I've wanted a libbitcoin since... well, since I first started
  browsing the bitcoin source code. @p{»»}

  @p{««}The consensus of the core bitcoin development team is to move
  towards a libbitcoin in small-ish, incremental steps, NOT to move to a
  full-blown API in one fell swoop. @p{»»}

  @p{««}The Bitcoin Consultancy folks disagree with that approach, and are
  moving ahead with a libbitcoin of their own that it rewritten from
  scratch, and I suspect there will be at least two or three other
  alternative implementations rewritten from scratch popping up over the
  next year or so. Which is why I'm spending a lot of time thinking about
  and working on cross-implementation testing. @p{»»}

  @p{««}(I'm supposed to be on vacation here in Australia, but I'll try to
  find some time to upload what I've done so far to github).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1066}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-25 00:41:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=31460.msg395848@s{hash}msg395848
@section 3 {tx}

  @p{««}Here's a scheme that would work: @p{»»}

    @p{(li} 1. Exchange creates a special bitcoin keypair for each
    exchange rate it wants to publish. @p{li)}

    @p{(li}E.g. maybe there is a 1mtgxbtcusd9873919fp876... address for
    mtgox btc/usd @p{li)}

    @p{(li} 2. Exchange funds that address with a bunch of bitcoins.
    @p{li)}

    @p{(li} 3. Every 10 minutes the exchange performs a send-to-self
    transaction FROM that address TO that address with the number of
    bitcoins that correspond to the current exchange rate. @p{li)}

  @p{««}Voila, exchange rate is broadcast to anybody who cares to listen.
  You know it is the exchange, because the exchange is the only entity
  that can spend bitcoins from the special exchange address. @p{»»}

  @p{««}You have to trust the exchange not to broadcast a bogus price...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1067}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-07-31 12:57:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=33122.msg415049@s{hash}msg415049
@section 3 {tx}

  @p{««}I followed the JSON-RPC-2.0 spec for errors, as described here:
  @p{»»}

    @p{(li}@s{(link)} @p{li)} (see section 5.1) @p{»»}

  @p{««}... with several bitcoin-specific additional error codes that I'd
  have to look at the source code to remember. @p{»»}

  @p{««}I thought I'd documented the additional bitcoin error codes, but
  maybe that information got lost in the wiki move that happened last year
  or maybe I'm mis-remembering. Quick grep through rpc.cpp gives: @p{»»}

   @s{code}

  @p{««} (-9, "Bitcoin is not connected!"); @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1068}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-01 22:57:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=33519.msg419299@s{hash}msg419299
@section 3 {tx}

  @p{««}For future reference: the Public Relations wiki page has good
  advice: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1069}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-02 05:36:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=33618.msg420099@s{hash}msg420099
@section 3 {tx}

  @p{««}blk0001.dat stores all of the transaction data for the block chain.
  @p{»»}

  @p{««}So to "inject" data into it you transmit valid transactions that
  are then included in blocks. Dan crafted transactions that contain the
  tribute message. @p{»»}

  @p{««}I think it is a neat hack. ("hack" in the sense of "clever,
  non-obvious way to use technology") I wonder how much it cost in
  transaction fees, or if he managed to do it entirely with free
  transactions... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1070}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-02 23:51:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=33836.msg422710@s{hash}msg422710
@section 3 {tx}

  @s{quotedtext}

  @p{««} Private insurance with reliable, reputable insurance companies.
  Private bonds deposited into reliable, reputable financial institutions.
  @p{»»}

  @p{««}All of which cost money, which was a problem a year ago when nobody
  really knew much of anything about bitcoin. @p{»»}

  @p{««}We need legal contracts with businesses that are in a legal
  jurisdictions where the contracts can be enforced in court. I don't
  think we'll get a non-governmental legal system in my lifetime, so I'm
  personally happy to rely on the imperfect government courts we've got
  today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1071}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-05 00:49:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=34458.msg429683@s{hash}msg429683
@section 3 {tx}

  @p{««}I whitelisted Dan and moved this thread here. @p{»»}

  @p{««}(yes, I'm beyond-a-reasonable-doubt-certain dakami is Dan Kaminsky,
  we had an email discussion about interesting-but-smushed-bug@s{hash}8 earlier
  in the week) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1072}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 03:10:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35011.msg436240@s{hash}msg436240
@section 3 {tx}

  @p{««}They're both unpredictable? @p{»»}

  @p{««}You lost both to some jerk on the Internet? @p{»»}

  @p{««}(six months from now): @p{»»}

  @p{««}You didn't appreciate them when you had them, but now they're gone
  you want them back? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1073}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 03:19:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35064.msg436268@s{hash}msg436268
@section 3 {tx}

  @p{««}No. @p{»»}

  @p{««}A better question might be: what would make me trust something like
  your BitDollars? @p{»»}

  @p{««}If you were bonded or insured for all of the bitcoins that you
  held, by a bank or insurance company or people I trusted (and were
  audited by that bank or insurance company or people to see how many
  bitcoins you were holding on behalf of other people), that might get me
  to trust you with real bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1074}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 15:08:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=28022.msg437469@s{hash}msg437469
@section 3 {tx}

  @p{««}Two pull requests seem appropriate: one for the generic issues
  (talk with TheBlueMatt about the upnp @s{hash}define, I believe it is working
  as designed), and one for DragonFly-specific stuff. @p{»»}

  @p{««}Frankly, DragonFlyBSD-specific stuff is unlikely to get pulled;
  there just aren't enough DragonFly-BSD systems to justify the work of
  maintaining support for it (according to bsdstats.org it isn't a very
  popular BSD variant).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1075}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 15:16:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=33490.msg437486@s{hash}msg437486
@section 3 {tx}

  @p{««}The wiki page is luke-jr's baby. Several of us are tired of having
  wiki-editing wars so we just ignore it. @p{»»}

  @p{««}Suggestions for a better "RFC process" are welcome; which open
  source project should we emulate? (e.g. bittorrent has BEPs, python has
  PEPs, are there other models to follow?)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1076}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 15:30:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=34458.msg437506@s{hash}msg437506
@section 3 {tx}

  @p{««}Alternative algorithms for accepting deep block-chain re-orgs sound
  like a research project to me. Before changing something that critical I
  would like to see simulations of how different re-org policies behave
  under different attack scenarios, and non-attack "what if there is a bug
  that causes an inadvertent block chain split" scenarios. @p{»»}

  @p{««}And I'd like to see a whitepaper that lays out the issues and
  summarizes simulation results. And lots of extra credit if it gets
  peer-reviewed and published in one of the IEEE or ACM journals. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1077}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-07 21:36:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11381.msg438343@s{hash}msg438343
@section 3 {tx}

  @p{««}Putting illegal content in the block chain and announcing it as an
  attempt to undermine Bitcoin seems like a good way to get yourself
  arrested. Much better than @p{(link}tweeting about exploits@p{link)}.
  @p{»»}

  @p{««}You'll have both law enforcement and techies trying to track you
  down, and given that people are already deploying
  @p{(link}de-anonymizing tools@p{link)} it seems pretty darn likely that
  you'd get caught.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1078}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-08 01:03:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=11381.msg438906@s{hash}msg438906
@section 3 {tx}

  @p{««}RE: protecting an innocent person: any lawyers here? @p{»»}

  @p{««}I have trouble believing that you could get into legal trouble for
  having illegal incidental data from legitimate activities on your
  computer. If you @p{(it}can@p{it)}, then we're all in trouble, because
  it is very easy to put illegal data in your web browser's cache (JPEG
  and other image file formats let you store arbitrary, not-normally-shown
  metadata, for example). I don't think it would be hard to convince a
  jury that the block-chain is like your web browser's cache@p{--} full of
  lots of incidental stuff that is needed for the system to work, but
  doesn't have anything to do with you. Now if you happen to have one of
  the private keys involved in the illegal transactions, THEN you should
  go directly to jail.... @p{»»}

  @p{««}Adding code to "shun" certain spend-able transactions wouldn't be
  hard, although I think that's a bad idea for the same reason it is a bad
  idea to respond to trolls on forums@p{--} you'd just encourage the bad
  guys by drawing attention to their misbehavior. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1079}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-08 01:14:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35204.msg438939@s{hash}msg438939
@section 3 {tx}

  @p{««}I'll be there.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1080}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-08 14:58:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=249.msg440377@s{hash}msg440377
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm resurrecting this old thread because I like to reality-check my
  predictions. @p{»»}

  @p{««}Number of bubbles so far: one. @p{»»}

  @p{««}(the $0.008 to $0.014 price rise turned out not to be a bubble; the
  recent $10 to $30 back down under $10 was definitely a bubble) @p{»»}

  @p{««}Zero to one bubbles and crashes per year for the next three years
  still seems about right. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1081}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-08 21:06:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=249.msg441274@s{hash}msg441274
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think the rise from less than $1 per bitcoin to over $30 per
  bitcoin was purely a speculative bubble, fueled by all the
  press/publicity. Even in the absence of global financial uneasiness I
  think a bubble was inevitable; maybe a lot of the interest in Bitcoin
  is/was driven by people looking for a deflationary escape, but I doubt
  it. Measure bitcoin prices in milligrams of gold (the time-tested
  deflationary escape) and you'll still see a big bubble and pop over the
  last few months. @p{»»}

  @p{««}I think it will be years (if we're lucky) before a significant
  number of investors look at Bitcoin as a deflationary escape from other
  assets. @p{»»}

  @p{««}What's your prediction for the number of bitcoin bubbles over the
  next three years? (measured against whatever basket of currencies or
  assets you like) I based my projections on "feels about right to me."
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1082}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-08 21:56:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35599.msg441385@s{hash}msg441385
@section 3 {tx}

  @p{««}Potential questions for the FAQ; these are all questions I wish I
  had insisted on getting answered before trusting MyBitcoin with some of
  my coins: @p{»»}

  @p{««}Are the bitcoins on deposit bonded or insured against theft or
  loss? @p{»»}

  @p{««}Are the bitcoins on deposit backed up off-site? How often? @p{»»}

  @p{««}How many people have access to the wallet? How do you know you can
  trust them, or how are they audited? @p{»»}

  @p{««}What happens if you decide Vibanko is not a viable business and has
  to be shut down? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1083}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-09 12:12:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35599.msg442927@s{hash}msg442927
@section 3 {tx}

  @s{quotedtext}

  @p{««} So factor out the swings in value by insuring in a more stable
  currency. @p{»»}

  @p{««}Obtaining insurance for "up to £X worth of bitcoins per account"
  seems like it aught to be possible. If X is a small number, then that's
  a strong indication that people shouldn't be using Vibanko for secure
  storage of coins. @p{»»}

  @p{««}If you can't find an insurance company that will cheaply sell you
  (say) £1,000 of coverage for (say) 10,000 accounts then that is an
  indication that maybe you're riskier than you think. Can you afford to
  self-insure, and put up a £10,000,000 bond to cover potential losses? Or
  work backwards: how large a bond can you afford to put up? Divide that
  by the expected number of users and that's a good indication of how much
  wealth users should trust you with.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1084}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-09 12:35:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20185.msg442995@s{hash}msg442995
@section 3 {tx}

  @p{««}The plan is the same as before: EFF coins will be redistributed via
  the Bitcoin Faucet. @p{»»}

  @p{««}Last week the folks at the EFF said they'd be sending the coins to
  a secure wallet I created for that purpose "tomorrow." @p{brk} I asked
  that they send them to address: 1vc3ZU4ae2cF6ZxqE44j5Ak3wfsZqybtb @p{»»}

  @p{««}I'll let you know what happens; they never told me where the coins
  are being held, it is possible they got caught in the mybitcoin
  disaster. @p{»»}

  @p{««}I'll keep that wallet secure and offline except to periodically
  top-up the Faucet's balance. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1085}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-09 13:10:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35599.msg443096@s{hash}msg443096
@section 3 {tx}

  @p{««}I'm curious to hear what other people think. I shut down ClearCoin
  when the value of its wallet threatened to get so large I was no longer
  comfortable self-insuring it with my own personal bitcoins. It is still
  shut down because I haven't found a group that I would trust to run it
  securely (and I don't want to take the time to raise the money and hire
  experts to run it properly). @p{»»}

  @p{««}We are starting to see well-capitalized, experienced companies
  creating bitcoin businesses; at this point, I think if you are holding
  other people's bitcoins then having insurance or posting a bond to
  self-insure up-to-some-value for each account is reasonable. @p{»»}

  @p{««}In my view, if your business model for your @p{(bf}free@p{bf)}
  service doesn't cover the cost of insurance or a bond, then you're just
  pushing a lot of hidden risk onto your users. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1086}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-09 14:45:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35532.msg443305@s{hash}msg443305
@section 3 {tx}

  @p{««}Alternative algorithms for determining the "best" block chain would
  be a good research topic, I think. @p{»»}

  @p{««}Model or simulate either a 'natural' block-chain splits (X% of the
  network gets disconnected for time T) or attacks (attacker with 51+% of
  hashing rate double-spends a transaction by surprising the network with
  a N-length better block chain). @p{»»}

  @p{««}Then see what the behavior is like under different potential
  algorithms for determining the best chain@p{--} the one we have now
  (most difficulty always wins) or some variant (like more recent blocks
  are given greater weight). @p{»»}

  @p{««}And think really hard about potential attacks, especially
  mixed-mode attacks (what if the attacker can mount a Sybil attack on one
  of the big mining pools? Or can DOS one or more of the big mining pools?
  etc) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1087}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-09 15:18:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6428.msg443377@s{hash}msg443377
@section 3 {tx}

  @p{««}Everybody likes this feature, and it feels like it is very close to
  being ready for inclusion. @p{»»}

  @p{««}There are two reasonable requests in this thread that I think
  should be implemented before this is pulled: @p{»»}

    @p{(li} 1. Pieter's change to the API, so the @p{lt}pubkey@s{gt} is
    extracted/verified from @p{li)}

    @p{(li}verifymessage @p{lt}bitcoinaddress@s{gt} @p{lt}signature@s{gt}
    @p{lt}message@s{gt} @p{li)}

    @p{(li} 2. ByteCoin's request that the @p{lt}signature@s{gt} be
    industry-standard-base64-encoded instead of hex or base58 encoded.
    @p{li)}

  @p{««} The nonce/no-nonce argument seems like "angels dancing on the head
  of a pin" to me; seems to me the tiny iota of theoretical added security
  (...sometime in the future maybe when SHA256 is broken or partly
  broken...) isn't worth the extra complexity.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1088}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-10 00:06:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8091.msg444668@s{hash}msg444668
@section 3 {tx}

  @s{quotedtext}

  @p{««} It will get pulled/released faster if you help test it. Pull the
  patch, compile a custom bitcoind, then run it and report any bugs. If
  you don't find any bugs, add a short note either here or in the PULL
  request. @p{»»}

  @p{««}Testing is currently the bottleneck for getting new features...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1089}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 00:32:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35752.msg450014@s{hash}msg450014
@section 3 {tx}

  @p{««}-wallet=foo.dat command-line param would be easy (unless you allow
  an absolute path, in which case the code that detects whether two
  instances of bitcoind are trying to write to the same wallet would have
  to be changed). @p{»»}

  @p{««}But if you pass it on the command-line, then wallet-stealers can
  just adapt and look in the process list to figure out where the wallet
  is. If you put it in the bitcoin.conf then the wallet-stealers can also
  look in the bitcoin.conf to figure out where it is. @p{»»}

  @p{««}I like the 'deterministic wallet' idea that's been floating around
  (enter a @p{(so}password@p{so)} passphrase at startup, and keys are
  magically derived from that @p{(so}password@p{so)} passphrase and never
  touch the disk at all). @p{»»}

  @p{««}Seems like there would be a clever way of combining that with
  @p{(link}white-box cryptography@p{link)} to make the private keys
  extremely trojan-resistant. @p{»»}

  @p{««}In which case the wallet-stealers will just rewrite the bitcoin
  address/amount after you press the "send coins" button... @p{»»}

  @p{««}@p{hrule} Edited to replace 'password' with 'passphrase' 

# ----------------------------------------------------------------------
@section 2 {ms1090}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 00:38:07 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36584.msg450030@s{hash}msg450030
@section 3 {tx}

  @p{««}FYI: I started a discussion of development priorities for the next
  release or two on the bitcoin-development mailing list: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1091}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 13:43:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=35382.msg451174@s{hash}msg451174
@section 3 {tx}

  @p{««}Half-baked thoughts on transaction relaying (I agree that it may
  become a major problem because there are no incentives to properly relay
  transactions right now): @p{»»}

  @p{««}I think writing code to reliably detect that a peer isn't relaying
   transactions is possible. Something like: @p{brk} Generating a new
   transaction: @p{»»}

    @p{(li}Pick a connected peer at random "P" @p{li)}

    @p{(li}Relay new transaction to all nodes EXCEPT P @p{li)}

    @p{(li}If, after a little while, P doesn't tell us about our new
    transaction then it is likely P is not relaying properly. @p{li)}

    @p{(li} (assumption is that we are not P's only connection, and it
    will get the transaction from its other peers) @p{li)}

  @p{««}And I think something like the above could be one of the metrics
  used to measure "ill-behaving peers" (other metrics might be number of
  double-spend transactions or orphan blocks received, number of
  spammy-looking transactions received, etc). If a peer is too
  ill-behaved, the penalty could be shunning@p{--} drop its connection and
  add its IP to a temporary refuse-connections list. @p{»»}

  @p{««}(maybe lesser penalties make sense, too@p{--} maybe
  order-of-relaying is based on good behavior, so the code announces new
  blocks/transactions to better-behaved peers fore worse-behaved peers).
  @p{»»}

  @p{««}If cheating miners find themselves disconnected from the rest of
  the network, that is a strong incentive not to cheat. @p{»»}

  @p{««}I'd really like somebody with a lot more network design experience
  than me to run some simulations and see what network behavior would be
  like with/without rules like I'm proposing. Or tell me that
  disconnecting ill-behaving nodes is a terrible idea because it makes it
  easy for an attacker to shatter the network into a gazillion pieces...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1092}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 14:18:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36218.msg451214@s{hash}msg451214
@section 3 {tx}

  @p{««}So... I got this unsolicited email: @p{»»}

  @s{quotedtext}

  @p{««} ... and I'm trying to figure out why my immediate reaction is
  "yuck." @p{»»}

  @p{««}I guess I just don't see the point of IxCoin. I just spent some
  time looking back through all the original poster's messages, and I
  don't see any prior discussion of goals of IxCoin, how it should be
  designed, etc. @p{»»}

  @p{««}If the goal is to let more people be early adopters of a new
  cyber-currency, then it seems to me giving early bitcoin adopters a
  bunch of IxCoin goes against that goal. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1093}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 18:05:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36218.msg451681@s{hash}msg451681
@section 3 {tx}

  @p{««}Couple of things: @p{»»}

  @p{««}First, I want to squash the "Satoshi mined a bunch of bitcoins on
  his own before releasing the bitcoin chain" idea. He publicly announced
  bitcoin version 0.1 six days after he generated the genesis block:
  January 9, 2009: @p{»»}

    @p{(li}@s{(link)}@s{at}metzdowd.com/msg10142.html @p{li)}

  @p{««}According to the block chain history, he generated about 10 blocks
  total before the announcement. And we know that he didn't pre-generate
  blocks because the genesis block contains a quote from the January 3rd
  Financial Times newspaper. @p{»»}

  @p{««}Second, I have no problem with alternative block chains, I just
  don't personally like how this particular alternative block chain is
  being promoted and developed and introduced. In particular, I think it
  is unfair to keep hundreds of thousands of whatever-coins for yourself,
  and it is unwise to think that a bitcoin variation that is "almost
  exactly like bitcoin, only different because... well, just because" will
  ever have anything more than speculative value. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1094}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-12 18:28:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36195.msg451738@s{hash}msg451738
@section 3 {tx}

  @p{««}Two different encryption schemes and/or passwords seems like a bad
  idea to me, both from a code maintenance/security point of view and from
  a usability point-of-view. @p{»»}

  @p{««}Can you expand on "private keys in base-58 export format are great
  for swapping around" @p{--} what's the use case? Who are you swapping
  with, and how? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1095}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-13 15:38:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36868.msg453528@s{hash}msg453528
@section 3 {tx}

  @s{quotedtext}

  @p{««} Really? You do realize that will just start an arms race with
  maxmint; he or she will write code to detect and ban bots, somebody will
  deploy bots via multiple IP addresses to workaround, maxmint will be
  forced to add a CAPTCHA, etc... @p{»»}

  @p{««}maxmint: it can be kind of fun to try to scam the scammers. If you
  detect them, just never let them win (but don't tell them you're not
  letting them win). @p{»»}

  @p{««}However, they'll eventually figure out you're doing that. The only
  way to win the arms race is to make it more expensive for the scammers
  to win than the reward. If I recall correctly, getting around
  one-per-IP-address and CAPTCHA restrictions costs a scammer a few US
  pennies. If you're giving away 1BTC worth $10, then you'll have to make
  sure the scammers will have to solve several thousand captchas to
  win.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1096}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-14 23:36:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=37126.msg456222@s{hash}msg456222
@section 3 {tx}

  @p{««}RE: negative account balances: @p{»»}

  @p{««}There is (was?) a patch proposed with an RPC call to prepare a send
  transaction, which would lock the inputs involved and return the
  transaction fee and a transaction id. And commit/reject RPC calls, which
  take the transaction id and either commit it or rejects it. That's the
  only really right way to estimate transaction fees before sending. I
  haven't reviewed the patch, and I don't think it has been thoroughly
  tested; there might be denial-of-service attacks possible or odd edge
  cases (e.g. could one customer who decides to go to lunch while the
  "this transaction will cost you 0.0005 BTC, OK/Cancel?" dialog is open
  tie up the entire wallet's balance, making sends fail for everybody?)
  @p{»»}

  @p{««}There's also an estimatetxfee patch, but the problem is that
  between the time you estimate the tx fee and the time the send happens
  the state of the wallet might change, making the estimate wrong. @p{»»}

  @p{««}The real question is why should customer A pay a transaction fee
  just because customer B funded their account with tons of tiny
  transactions? If customer A puts 1,000 bitcoins in their account and
  pays 0 fee, they're going to be pretty upset at you if you charge them
  to withdraw @p{(bf}THEIR@p{bf)} money from the account. @p{»»}

  @p{««}For ClearCoin, I just treated transaction fees as a cost of doing
  business, and refunded customer accounts when a send resulted in a
  transaction fee (via the RPC move method from a special FEES account
  that I pre-funded to cover transaction fees). @p{»»}

  @p{««}So sends look like: @p{»»}

    @s{code}

  @p{««}if txinfo says a fee was paid: @p{»»}

    @p{(li} move "FEES" "account" @p{lt}amount-of-fee-paid@s{gt} @p{li)}

  @p{««} RE: static addresses @p{»»}

  @p{««}I don't follow. You mean have one address per account? You could
  call getaddressesbyaccount and the return the first address or (if empty
  array) return getaccountaddress? Or if you create an account when a user
  signs up for your service, call getaccountaddress and then you KNOW that
  getaddressesbyaccount will return at least one address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1097}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-15 01:16:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20185.msg456413@s{hash}msg456413
@section 3 {tx}

  @p{««}Update: @p{»»}

  @p{««}The EFF donation account/address was at mybitcoin, so half of them
  are gone. @p{»»}

  @p{««}I received 1,879 from the mybitcoin claims process. They are now
   safe in an offline, encrypted wallet; here is the transaction: @p{brk}
   @s{(link)} @p{»»}

  @p{««} @p{hrule} According to block explorer, 3515.06 BTC were donated to
  the donation address I had for them: @p{brk} @s{(link)} @p{»»}

  @p{««}49% of that would have been about 1,722 BTC, not 1,879. I'm
  guessing the difference is because of donations from other mybitcoin
  customers just crediting the eff account without generating a
  block-chain transaction. @p{»»}

  @p{««}Before sending coins to the Faucet, I think I'll create a patch to
  always send "change" to the same address, so it is really easy to keep
  track of these bitcoins and make sure they're not sent anywhere other
  than the Faucet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1098}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-15 01:49:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20185.msg456461@s{hash}msg456461
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, I'll send... oh, I dunno, $200 or so worth of bitcoins at a
  time to the Faucet. @p{»»}

  @p{««}RE: not holding the EFF in high esteem: I still strongly support
  the EFF. They're good people working to make the world a better place,
  and I trust them to know better than I do whether or not accepting
  bitcoin donations is good for both them and the bitcoin project. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1099}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-15 14:08:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=37157.msg457384@s{hash}msg457384
@section 3 {tx}

  @p{««}I'd say the short answer to "is it possible to accept them again in
  the near future" is no (where "near" is in the next six months). @p{»»}

  @p{««}I agree with Maged@p{--} before enabling new opcodes, I'd like to
  see a peer-reviewed academic-style paper that works through the security
  implications of the existing set of opcodes and gives a nice framework
  for thinking about new (or disabled old) opcodes. Doing that is way
  outside my own personal level of expertise; I know only enough about
  designing secure algorithms to know that I have no idea whether or not
  re-enabling OP_XOR would have security implications for bitcoin. @p{»»}

  @p{««}Same goes for enabling nLockTime / transaction replacement,
  although I suspect that proving that transaction replacement doesn't
  open up any subtle attacks may be harder than proving security
  properties of opcodes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1100}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-15 14:59:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=37152.msg457469@s{hash}msg457469
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bitcoin addresses are not public keys@p{--} they are hashes of
  public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with
  a version number and checksum, to be annoyingly specific). @p{»»}

  @p{««}I agree that associating a message with a bitcoin transaction would
  be spiffy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1101}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-17 17:48:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=36788.msg463423@s{hash}msg463423
@section 3 {tx}

  @p{(li} 1 for vector76's hypothesis.  @p{li)}

  @p{««}If mybitcoin was running bitcoin behind Tor, and had just one
  connection (through a Tor exit node) to the rest of the bitcoin network,
  then they'd be particularly susceptible to this 1-confirmation attack.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1102}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-18 14:09:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=37886.msg465327@s{hash}msg465327
@section 3 {tx}

  @p{««}Transactions have multiple inputs and outputs. @p{»»}

  @p{««}If you have 0.5BTC inputs, then 50 of them will be bundled together
  and a transaction with 50 inputs and one output will be created. @p{»»}

  @p{««}... but that's not what will actually happen. A
  50-input-transaction will be over the "small enough to be free"
  transaction size limit, so 51 will be bundled together and a transaction
  with 51 inputs and two outputs (one to the destination, one back to you
  for any change leftover after paying the transaction fee) will be
  created. @p{»»}

  @p{««}There is no ledger, there are just transactions with inputs and
  outputs. Your bitcoin balance is the sum of all the outputs to addresses
  that you own that haven't yet been used as input to another transaction.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1103}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-19 14:55:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6284.msg468016@s{hash}msg468016
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, but if two blocks are found with the same difficulty then
  they are considered equal work-wise (even if one has a smaller hash
  value@p{--} the "Bits" field in the block is used to compute chain work,
  not the block hash). @p{»»}

  @p{««}If there are several valid tip-of-block-chain choices all of which
  have the same work, then miners are free to build off whichever one they
  like. The rule everybody (I think!) is using now is "build off the one
  seen first." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1104}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-22 18:12:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4530.msg473865@s{hash}msg473865
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, would you be interested in building? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1105}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 01:02:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38620.msg474612@s{hash}msg474612
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why couldn't the-collective-we only revoke the double-spends (and
  subsequent txns that depended on them) ? @p{»»}

  @p{««}A hard-coded list of invalid txids wouldn't be hard to insert into
  the is-valid-transaction checks, and that along with a blockchain
  checkpoint would work just fine. Valid transactions on the bad chain
  would move to the new chain (actually, they'd already be on the
  non-attacker chain, since the miners on both sides of the block split
  would have included them). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1106}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 01:16:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38562.msg474630@s{hash}msg474630
@section 3 {tx}

  @p{««}If you need a stable testing environment, the self-contained
  testnet-in-a-box works very nicely: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}You do have to remember to run -noirc or keep your testnet listen
  port closed, because if a 'real' testnet node connects to you you'll get
  the 'real' testnet block-chain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1107}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 01:23:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6150.msg474642@s{hash}msg474642
@section 3 {tx}

  @p{««}I enjoyed the conference, and I usually hate conferences. @p{»»}

  @p{««}Apologies to everybody who I met and whose name I've already
  forgotten. My secret super-power is forgetting names. @p{»»}

  @p{««}And congratulations and a big Thank You to Bruce and company for
  organizing and making it happen! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1108}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 21:02:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38903.msg476326@s{hash}msg476326
@section 3 {tx}

  @p{««}I've been working on a proposal to enable (1,2)-of-(1,2,3)
  signatures-required as standard transaction types. @p{»»}

  @p{««}I'll start another thread with more information... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1109}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 21:17:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg476360@s{hash}msg476360
@section 3 {tx}

  @p{««}Sunday at the bitcoin conference I led a little brainstorming
  session on extending the set of 'standard' transaction types, and I've
  been picking people's brains via email and IRC chat (and pull request
  comments) to work through the details. @p{»»}

  @p{««}My motivation for wanting to do this NOW is because it will allow
  features like: @p{»»}

  @p{(li}  Multi-device confirmation of spends, so if your computer is
  infected by a trojan it cannot spend all of your coins.  @p{li)}

  @p{(li}  Master-key emergency backup, so if you lose your wallet (and all
  of its backups) you can get the master key from your safe deposit box
  and recover all of your coins  @p{li)}

  @p{««}It will also enable third-party escrow and some other nifty
  features that aren't as important to me. The first step in doing all of
  these things is to work out the lowest-level transaction format and to
  allow those transactions to be relayed and included in blocks. That is
  ALL I am proposing right now (actually implementing something like
  multi-device spend confirmation will require a little protocol for the
  devices to communicate, a new kind of bitcoin address that people will
  send into, etc etc etc). @p{»»}

  @p{««}Working out a common way of doing (for example)
  1-of-2-keys-required transactions will make it much easier for sites
  like blockexplorer to display them intelligently, and will generally
  make life happier for anybody writing tools that look at the blockchain.
  @p{»»}

  @p{««}I'd rather not have this turn into a "lets get rid of the
  IsStandard() check" or "lets re-enable a bunch of currently disabled
  opcodes", so if you want to talk about that start a new thread. @p{»»}

  @p{««}Current draft proposal is here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1110}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-23 22:51:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38932.msg476510@s{hash}msg476510
@section 3 {tx}

  @p{««}You're right, I think even without blockexplorer Satoshi would've
  added the IsStandard() check. There were a series of "oops, didn't think
  of that" moments that pushed him to disable a bunch, tighten up some
  requirements on existing opcodes, and add IsStandard(). @p{»»}

  @p{««}In general, I believe in "whitelisting" instead of "blacklisting"
  to try to prevent harm. Enable functionality that you can prove (or
  convince yourself beyond a reasonable doubt) will not cause problems.
  I'm strongly influenced from watching web content systems that fail
  repeatedly trying to detect malicious HTML or CSS. @p{»»}

  @p{««}RE: allow non-standard transactions but give them a very low
  priority so they take a very long time to confirm: I like that idea.
  I'll have to think a little more about possible unintended consequences
  (will they tend to fill up transaction memory pools and crowd out
  low-priority standard transactions? Do they need their own
  memory-limited pool? etc) @p{»»}

  @p{««}The intent was always to relax the rules when SPV/headers-only mode
  was implemented and non-mining clients didn't need to download the
  entire block chain. However, nobody tackled that work (it is on my TODO
  list, right after I tackle some testing framework work).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1111}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 00:08:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg476630@s{hash}msg476630
@section 3 {tx}

  @s{quotedtext}

  @p{««} The multi-device use-case I'm imagining: @p{»»}

  @p{««}I sign up with Acme Bitcoin Security Solutions, Inc. They give me a
  WalletProtection public key (or bitcoin address, doesn't matter) and a
  unique-for-me URL. I put the address/pubkey into my bitcoin client as
  "Second factor off-device Send Authentication." Or something. @p{brk}
  (ABBS also sends me the private key in the mail and tells me to keep it
  safe in case they go out of business) @p{»»}

  @p{««}Now I want all coins sent to me to require signatures from keys in
  my wallet AND the ABBS key to spend. @p{»»}

  @p{««}What bitcoin address do I give to people so that all coins going
  into my wallet have that property? @p{»»}

  @p{««}If it is raw CHECKMULTISIG, then I need to give out addresses
  containing 2 full public keys. Which would be 186 characters in base58
  and look something like this: @s{code}
  @p{»»}

  @p{««}Using 20-byte hashes and the more complicated 2-of-2 transaction
  i'm proposing, the address is a more reasonable 61 chars: @s{code} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1112}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 00:15:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg476643@s{hash}msg476643
@section 3 {tx}

  @s{quotedtext}

  @p{««} Clients could make c the base for a deterministic key; derive a
  series of keys from c, and use them in subsequent transactions. (given
  full public key for c, you can derive a series of public keys without
  having the private key) @p{»»}

  @p{««}Same could be done for the 'wallet protection service' key b @p{--}
  every time you use b, contact the protection service and ask for a b'
  derived deterministically from b. Then b'', b''', etc... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1113}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 00:36:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6150.msg476675@s{hash}msg476675
@section 3 {tx}

  @p{««}I uploaded a PDF file of my slides here: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1114}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 00:59:16 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38954.msg476696@s{hash}msg476696
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because I want to enable these features reasonably soon, and
  modifying the way CHECKSIG works means a blockchain fork for clients
  that haven't upgraded. Which means giving at least 6 months notice to
  give everybody time to upgrade their clients. @p{»»}

  @p{««}At some point that will make sense, but with what I'm proposing it
  is not necessary. When SHA3 is finalized or a weakness is found in ECDSA
  or SHA256 maybe it'll be time to do that... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1115}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 17:34:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg477829@s{hash}msg477829
@section 3 {tx}

  @p{««}Phew. Ok, I feel better; consensus seems to be that enabling some
  or all of the proposed 'new standard' transactions is a good idea. @p{»»}

  @p{««}All the rest (new address format? send to old addresses and
  immediately resend? etc etc etc) can be argued to death later. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1116}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-24 18:04:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=39064.msg477887@s{hash}msg477887
@section 3 {tx}

  @p{««}My worry is that we'll schedule a blockchain split 6 months from
  now, and between now and then somebody implements a secure, way-cool,
  everybody-decides-to-use, way to use your email address as a bitcoin
  address. @p{»»}

  @p{««}So my receiving address is
  '@p{(link}gavinandresen@s{at}gmail.com@p{link)}' and suddenly all the arguing
  over length of the bitcoin addresses used behind the scenes was just a
  huge waste of time. @p{»»}

  @p{««}I'm as guilty of doing stuff like that as the next geek@p{--} I can
  get so focused on one little bit of a problem I don't even realize
  solving a larger problem makes the whole issue go away. Slap me upside
  the head if you see me going down that path...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1117}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-25 02:06:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg478755@s{hash}msg478755
@section 3 {tx}

  @s{quotedtext}

  @p{««} Those are "Proposal 1" @p{--} enabling all the 'plain-old'
  OP_CHECKMULTISIG transactions. @p{»»}

  @p{««}groffer reports finding a bug in CHECKMULTISIG (pops too many items
  off the stack), which makes me wonder if it would be better to avoid it.
  For small n, using CHECKSIG multiple times is straightforward and
  doesn't make the transactions much larger. @p{»»}

  @p{««}The (a and b) OR c transaction with public keys instead of
  addresses isn't in the proposal, but for consistency's sake I agree it
  should be. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1118}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-08-27 22:28:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=39705.msg485101@s{hash}msg485101
@section 3 {tx}

  @p{««}I got a copy, too. If you use gmail, use the 'Report phishing'
  function (in the Reply drop-down menu). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1119}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-01 13:51:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40430.msg496145@s{hash}msg496145
@section 3 {tx}

  @s{quotedtext}

  @p{««}No hard limits, but the bitcoind "accounts" code hasn't been
  optimized for that. For example, computing an account's balance loops
  through all transactions in the wallet, so will take an increasing
  amount of time the more transactions you have in the wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1120}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-02 20:29:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=39909.msg499897@s{hash}msg499897
@section 3 {tx}

  @s{quotedtext}

  @p{««} +1 

# ----------------------------------------------------------------------
@section 2 {ms1121}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-03 02:07:59 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40430.msg500646@s{hash}msg500646
@section 3 {tx}

  @p{««}Optimizing the accounts code to add a berkeley db index table that
  indexed wallet transactions by account, and that cached account balances
  (and invalidated or updated the cache on receive/send) shouldn't be
  terribly hard for somebody who already knows c++ and berkeley db. @p{»»}

  @p{««}It is not on my short-term TODO list because there are too many
  other higher priority things on my TODO list, but a nice clean
  well-tested upward-compatible patch would be most welcome. @p{»»}

  @p{««}PS: for ClearCoin, I used the "bitcoind keeps track of the
  bitcoins" architecture, and I never regretted it@p{--} no problems with
  synchronization, less possibility for MtGox-like hacks that create
  mythical bitcoin balances out of thin air by adding an entry to a
  database. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1122}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-05 00:28:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=41456.msg505156@s{hash}msg505156
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good idea. @p{»»}

  @p{««}The developers listed on bitcoin.org are the people who have 'push'
  rights to the github source tree, but I like the git approach. @p{»»}

  @p{««}Who wants to volunteer to make it happen? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1123}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-05 20:37:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=41345.msg507159@s{hash}msg507159
@section 3 {tx}

  @p{««}Y'all probably want this: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}However, I don't think you can fix all the problems that a fixed
  transaction fee cause; the real problem is that basic economics says
  that you need to let the price of a scare resource change, ideally in a
  market, to match the underlying real costs. @p{»»}

  @p{««}(bitcoin's fee structure isn't right either, and fixing it to
  create a market between miners and clients is high on the TODO list)
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1124}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-05 20:55:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=15276.msg507189@s{hash}msg507189
@section 3 {tx}

  @s{quotedtext}

  @p{««}I think everybody would like to merge bitcoin-qt as soon as the 0.4
  release is shipped (see the bitcoin-dev mailing list for the current
  known bugs). @p{»»}

  @p{««}Closing the dozens of wxWidgets-related GUI bugs in the issues list
  will give me great pleasure...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1125}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-06 23:25:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=41718.msg510674@s{hash}msg510674
@section 3 {tx}

  @p{««}Very nice bitrick! @p{»»}

  @p{««}By the way, this patch speeds up initial download quite a lot:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}...as do these, which have already been pulled into git head: @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1126}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-07 01:44:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=3612.msg510969@s{hash}msg510969
@section 3 {tx}

  @p{««}0.3.24 Linux/Windows releases weren't built on EC2, but was built
  on 'gitian' virtual machines (lookup trusted build process here for more
  info, or get in touch with devrandom). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1127}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-09 13:21:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=42465.msg516789@s{hash}msg516789
@section 3 {tx}

  @p{««}I haven't seen anybody post about what would be my biggest worry if
  I were trying out alternative block chains. I realize this may be
  perceived as "Gavin is FUD'ding anything that isn't bitcoin!" (FUD ==
  Fear, Uncertainty and Doubt) But I think some of you might be forgetting
  some basic computer security fundamentals in the excitement to be early
  adopters. @p{»»}

  @p{««}When I first heard about bitcoin, my questions were: @p{»»}

  @p{««}1) Can it possibly work (do the ideas for how it works make sense)?
  @p{brk} 2) Is it a scam? @p{brk} 3) If it is not a scam, could it open
  my computer up to viruses/trojans if I run it? @p{»»}

  @p{««}I answered those questions by: @p{»»}

  @p{««}1) Reading and understanding Satoshi's whitepaper. Then thinking
  about it for a day or two and reading it again. @p{brk} 2) Finding out
  everything I could about the project. I read every forum thread here
  (there were probably under a hundred threads back then) and read
  Satoshi's initial postings on the crypto mailing list. @p{brk} 3)
  Downloaded and skimmed the source code to see if it looked vulnerable to
  buffer overflow or other remotely exploitable attacks. @p{»»}

  @p{««}If I were going to experiment with an alternative block-chain, I'd
  go through the same process again. But I'm an old conservative
  fuddy-duddy. @p{»»}

  @p{««}If you want to take a risk on a brand-new alternative block-chain,
  I'd strongly suggest that you: @p{»»}

  @p{««}1) Run the software in a virtual machine or on a machine that
  doesn't contain anything valuable. @p{brk} 2) Don't invest more money or
  time than you can afford to lose. @p{brk} 3) Use a different passphrase
  at every exchange site. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1128}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-09 19:18:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=42531.msg517818@s{hash}msg517818
@section 3 {tx}

  @p{««}They won't lose any money to fees, because they won't broadcast
  their transactions-to-self, they'll just include them in blocks that
  they create. @p{»»}

  @p{««} So, evil miner does: @p{»»}

  @p{««}Gets some myselfcoins. @p{brk} Creates transactions that pays
  themselves the myselfcoins, and pays BIG fees. @p{brk} Does NOT
  broadcast those transactions. @p{brk} ... eventually mines a block that
  contains those transactions (they're a miner, they can put whatever
  transactions they like in their blocks). @p{»»}

  @p{««}Then does that again and again, re-using the same coins, getting
  richer and richer from the FEES+10% @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1129}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-11 17:56:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43442.msg519249@s{hash}msg519249
@section 3 {tx}

  @p{««}As an experiment, I've uploaded a Mac .dmg disk image with 0.4rc2
  binaries to: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}I'd like to switch from sourceforge to github for binary release
  downloads, because sourceforge doesn't support https for downloads.
  @p{»»}

  @p{««}Help improving the script I used to create the .dmg file would be
  most appreciated; see this branch for what I done did: @p{»»}

  @s{(link)} 
  
  @p{««}@p{(so}For some reason setting the "Drag and
  drop to install" background image isn't working... shasum checksum is: 
  @s{code} @p{so)} @p{»»}

  @p{««}Fixed. New shasum checksum is: @s{code} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1130}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-12 01:05:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43442.msg519983@s{hash}msg519983
@section 3 {tx}

  @p{««}The yoursway create-dmg script had the same problem. @p{»»}

  @p{««}I changed the approach to using a "template" .dmg file, as
  described here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The .dmg includes Bitcoin.app, a compiled bitcoind daemon, and the
  source code .zipped up.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1131}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-12 01:54:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43495.msg520046@s{hash}msg520046
@section 3 {tx}

  @p{««}Hi Jeremy! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1132}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-12 15:39:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43465.msg520923@s{hash}msg520923
@section 3 {tx}

  @p{««}The testnet has suffered
  rewrite-the-block-chain-with-more-hashing-power attacks. @p{»»}

  @p{««}It does bad things to your wallet, if your wallet contains
  transactions that depend on previously mined but now-no-longer-valid
  blocks. I suspect it will cause lots of heartburn for exchanges; this
  patch from sipa (which hasn't been extensively tested because long
  block-chain re-orgs on the main chain are not an issue) might help:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Alternatively, removing all the wtx wallet transactions stored in
  the wallet and then running with -rescan should get back to a sane
  state. Although an exchange may very well find customers end up with
  negative balances after doing that, and customers will likely be upset
  that their balances are likely to change from what they think they have
  if they've deposited invalid-under-the-new-chain transactions. @p{»»}

  @p{««}Successfully bootstrapping an alternative chain starting from a low
  difficulty, given that there are people with lots of potential hashing
  power and the willingness to mess around with the chain "just because
  they can," seems like a hard problem to me, although if people were
  willing to accept some centralization until hashing power got to a
  "safe" level it could be solved by a central authority publishing
  block-chain checkpoints every X blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1133}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-12 19:38:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=42417.msg521460@s{hash}msg521460
@section 3 {tx}

  @p{««}RE: hidden recipient address: @p{»»}

  @p{««}I dug deeper into the Script OPs when working on the multisig
  proposal, and OP_ADD can't add bignums, so the 'hidden recipient' script
  won't work. @p{»»}

  @p{««}@p{(so}A simpler version would, though; I'll update the
  wiki.@p{so)} 

# ----------------------------------------------------------------------
@section 2 {ms1134}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-12 23:31:11 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=42417.msg522046@s{hash}msg522046
@section 3 {tx}

  @p{««}RE: where in the code: script.cpp @p{»»}

  @s{code}

  @p{««} ... and all of the arithmetic binary ops do a CastToBigNum() @p{»»}

  @p{««}nMaxNumSize = 4 means numbers added must be 32-bits or less. @p{»»}

  @p{««}RE: simpler version being redeemed by anybody by rewriting: D'oh!
  Right, definitely need a signature so the transaction can't be modified
  between being broadcast and being included in a block. I'll remove it
  from the wiki page. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1135}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-14 00:37:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43821.msg524411@s{hash}msg524411
@section 3 {tx}

  @s{quotedtext}

  @p{««} Non-standard transactions are allowed-by-default on the test
  network. So people can test things out. @p{»»}

  @p{««}They are "discouraged-by-default" on the main network (discouraged
  means not relayed to peers, and not included in blocks by the default
  mining code). @p{»»}

  @p{««}I think etotheipi is right: last I heard, Eligius was the only
  mining pool with different rules for non-standard transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1136}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-14 19:38:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44028.msg525712@s{hash}msg525712
@section 3 {tx}

  @p{««}I think it would be wise for any alternative block-chain to
  discourage creation of exchanges for at least a month or three to get
  the bugs out. @p{»»}

  @p{««}That should also help build trust that the alternative chain
  developers/promoters aren't just trying to make some quick BTC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1137}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-14 21:27:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44078.msg525928@s{hash}msg525928
@section 3 {tx}

  @p{««}A Radeon 6990 has 4 gigabytes of ram. @p{»»}

  @p{««}If the task is "find a number that bcrypts/scrypts to less than a
  given hash target," I don't see anything that would stop a GPU
  programmer from implementing bcrypt/scrypt on the CPU and parallelizing
  at the try-different-nonces level. @p{»»}

  @p{««}Maybe I'm missing something; I'm probably biased because I worked
  at SGI from 1988 to 1996 and saw first-hand the evolution of GPUs from
  very-special-purpose chips with very limited memory to
  very-general-purpose vector-processing pipelines with very fast access
  to lots of memory. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1138}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-14 22:49:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=42465.msg526061@s{hash}msg526061
@section 3 {tx}

  @s{quotedtext}

  @p{««} Relevant discussion on the bitcoin-dev mailing list is here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1139}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 14:40:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44138.msg528989@s{hash}msg528989
@section 3 {tx}

  @s{quotedtext}

  @p{««} Please don't spread misinformation. @p{»»}

  @p{««}I agreed to join TruCoin a couple of months ago, because I knew
  Eric (chaord) and Chris (cbrunner) through these forums and I think
  their vision and experience give TruCoin a really good chance of being
  an important company in the bitcoin economy. @p{»»}

  @p{««}And they hired me because TruCoin won't go anywhere if core bitcoin
  falls apart. I will (and have) mostly be working on core bitcoin issues,
  jumping in and writing code that I think is critically needed that
  nobody else is stepping up to write and working to make bitcoin as
  stable and secure as possible. @p{»»}

  @p{««}If Eric and Chris tell me to do something that is bad for bitcoin,
  I'll let them know what I think. If they suddenly lose their minds and
  stop listening, then I'll quit. @p{»»}

  @p{««}If I lose my mind and start doing things that are bad for bitcoin
  as a whole (or if I start trying to do things to bitcoin-core that
  benefit TruCoin over everybody else), then you-all should fire me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1140}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 15:30:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44326.msg529046@s{hash}msg529046
@section 3 {tx}

  @p{««}When did it happen: I made time to fix it a few days ago. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1141}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 15:49:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44330.msg529078@s{hash}msg529078
@section 3 {tx}

  @p{««}So the plan is for the next release of bitcoin to switch from the
  wxWidgets GUI we have now to the vastly nicer QT GUI that John Smith
  created. @p{»»}

  @p{««}I spent some time yesterday compiling Qt and bitcoin-qt, and some
  time this morning doing a very quick code review (executive summary:
  looks great!). @p{»»}

  @p{««}I'm mostly posting this as a brain dump of "stuff not to forget"
  when it is time to pull QT and remove WX. @p{»»}

  @p{««}Major behavioral differences I noticed during code review: @p{»»}

  @p{««} @p{(li}Does not generate new receiving addresses automatically
  (good idea, I think, but may be controversial).@p{li)}

    @p{(li}Cannot act as a rpc client (ok with me, we'll still
    compile/ship a headless bitcoind)@p{li)}

  @p{««}Will-need-to-be-done stuff: @p{»»}

  @p{««} @p{(li}Find and replace or remove references to wxwidgets in
  documentation, makefiles, etc.@p{li)}

    @p{(li}Change makefiles to track rpc.cpp @p{--}@s{gt} bitcoinrpc.cpp
    name changes@p{li)}

    @p{(li}The QT library is LGPGL licensed; do we need to change READMEs
    or other files?@p{li)}

  @p{««}... and probably a bunch of other little things I didn't notice or
  I forgot to write down. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1142}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 17:07:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44330.msg529172@s{hash}msg529172
@section 3 {tx}

  @p{««}RE: cannot act as a RPC client: @p{»»}

  @p{««}I believe it will still be able to act as a RPC server. @p{»»}

  @p{««}So you can run the GUI with the -server switch, but you'll have to
  talk to it using (for example) @p{»»}

    @p{(li}bitcoind getinfo @p{li)}

  @p{««}... as opposed to today, where you can run "bitcoin -server" to get
  the GUI and then run "bitcoin getinfo" to talk to the running GUI
  process. @p{»»}

  @p{««}RE: why switch: because no wxwidgets programmers stepped up and
  made it better. And from what I can see, QT is more popular and
  supported (so there are more programmers able and willing to help
  improve). @p{»»}

  @p{««}RE: screen shots: See the bitcoin-qt thread in the Alternative
  Clients sub-forum here. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1143}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 21:56:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44330.msg529670@s{hash}msg529670
@section 3 {tx}

  @s{quotedtext}

  @p{««} 0.4.0 : Out real soon (0.4.0 release candidate 2 binaries are
  available on sourceforge now) @p{»»}

  @p{««}0.4.1 : I'd give about a 80% chance of happening (major bug or
  security problem found in 0.4.0) @p{brk} 0.4.2 : I'd give about a 20%
  chance of happening (major bug or security problem found in 0.4.1) @p{»»}

  @p{««}0.5.0 : Will be the Qt release. @p{»»}

  @p{««}Beyond that... who knows? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1144}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-16 22:10:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44145.msg529690@s{hash}msg529690
@section 3 {tx}

  @p{««}sendfrom needs the minconf to know if it should fail because of too
  few confirmed coins in the account. @p{»»}

  @p{««}move used to need minconf for essentially the same reason, but as
  of (some release in the past) it always succeeds. @p{brk} E.g. if
  account A has 5 0-confirmation bitcoins and 5 1-confirmation bitcoins
  then: @p{»»}

    @p{(li}move "A" "B" 10 @p{li)} ... used to fail, because A's
  1-confirmation balance was only 5. @p{»»}

  @p{««}Now it will succeed, giving it a -5 one-confirmation balance. move
  "A" "B" 100 will also now always succeed, making A's balance go
  negative. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1145}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-17 03:44:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43641.msg530093@s{hash}msg530093
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. @p{»»}

  @p{««}There are
  1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
  possible bitcoin addresses. @p{»»}

  @p{««}If your calculator can handle numbers that big, you can play around
  with how long it would take to try generate one quadrillionth of them if
  you could generate a trillion per second. @p{»»}

  @p{««}(I get an answer of a bit over 46 trillion years) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1146}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-17 04:29:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44415.msg530161@s{hash}msg530161
@section 3 {tx}

  @p{««}Linux and Windows and Mac binaries are available at sourceforge:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}And HTTPS download from the Amazon Cloudfront content distribution
   network: @p{brk} @s{(link)} @p{brk} @s{(link)} @p{brk} @s{(link)}
   @p{brk} @s{(link)} @p{»»}

  @p{««}The d24z.... downloads are an experiment; I like that they're
  https, I don't like the obscure d24z... URL (that's actually github's
  CloudFront id; I asked, and they have no objections to linking directly
  to the https version of the downloads). @p{»»}

  @p{««}Executive summary release notes: @p{»»}

  @p{««}The main feature in this release is wallet private key encryption;
  @p{brk} you can set a passphrase that must be entered before sending
  coins. @p{brk} See below for more information; if you decide to encrypt
  your wallet, @p{brk} WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE
  LOCATION. If you @p{brk} forget or lose your wallet passphrase, you lose
  your bitcoins. @p{brk} Previous versions of bitcoin are unable to read
  encrypted wallets, @p{brk} and will crash on startup if the wallet is
  encrypted. @p{»»}

  @p{««}Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
  @p{brk} (bdb version 4.8) than previous versions (bdb 4.7). If you
  upgrade @p{brk} to version 0.4 and then revert back to an earlier
  version of bitcoin @p{brk} the it may be unable to start because bdb 4.7
  cannot read bdb 4.8 @p{brk} "log" files. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1147}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-18 16:10:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44415.msg532368@s{hash}msg532368
@section 3 {tx}

  @p{««}RE: long delay, no window on startup: will be made much better by
  the QT splash screens in bitcoin 0.5. @p{brk} RE: lots of GUI bugs:
  whole rafts of wxwidgets-related bugs will go away with the switch to QT
  in bitcoin 0.5. @p{»»}

  @p{««}RE: incompatible on older version of windows: I don't know nuthin
  about windows compatibility, somebody want to volunteer to investigate?
  Is bitcoin 0.4 less compatible for some reason than 0.3.24 was?
  (shouldn't be...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1148}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-19 19:53:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg534485@s{hash}msg534485
@section 3 {tx}

  @p{««}Status of the multisig proposal: There are two, a stripped-down,
  simplified one: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and a supports-more-use-cases-but-is-more-complicated one:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1149}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-20 13:01:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44415.msg535711@s{hash}msg535711
@section 3 {tx}

  @s{quotedtext}

  @p{««}No. @p{»»}

  @p{««}Why not? I don't remember. Why would you want to un-encrypt it? (I
  ask because if you want to save an unencrypted backup then maybe a
  better feature would be "backup wallet" with an option to backup
  encrypted or unencrytped)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1150}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-20 16:00:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44652.msg535973@s{hash}msg535973
@section 3 {tx}

  @p{««}There's been a little discussion on the bitcoin-dev mailing list.
  @p{»»}

  @p{««}I think it is a great idea, but "BEP" is the wrong name (because
  there are already BitTorrent Enhancement Proposals). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1151}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-20 20:26:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44423.msg536351@s{hash}msg536351
@section 3 {tx}

  @s{quotedtext}

  @p{««}GPUs suck at accessing main memory. @p{»»}

  @p{««}But they're very, very good at accessing on-board memory. See, for
   example (from a couple of years ago) @p{brk} @s{(link)} @p{»»}

  @s{quotedtext}

  @p{««}I predict it'll take... mmm... 3 weeks after source code is
  released for the first faster-on-a-GPU solidcoin 2.0 closed-source miner
  to come out. 8 weeks until there's an open-source one available. @p{»»}

  @p{««}But my predictions are often wrong. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1152}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-20 20:29:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44906.msg536357@s{hash}msg536357
@section 3 {tx}

  @s{quotedtext}

  @p{««}Pronounced "barfy" @s{huh} 

# ----------------------------------------------------------------------
@section 2 {ms1153}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-21 12:44:29 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44954.msg537521@s{hash}msg537521
@section 3 {tx}

  @p{««}I like the idea of trying to prove that the DoS code doesn't
  increase the chance of network fragmentation. @p{»»}

  @p{««}The DoS countermeasures should be careful not to penalize or ban
  peers for any messages that the client will (or might, in another
  situation) relay. @p{»»}

  @p{««}For example, double-spent transactions don't trigger the DoS
  countermeasure code. @p{»»}

  @p{««}That should be sufficient to prevent split-the-network attacks; if
  an attacker wants to try to split the network, the only way the attacker
  would be successful is if it could somehow send messages to peers that
  ARE relayed and trigger disconnections elsewhere in the network. @p{»»}

  @p{««}Looking through the patch: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... I see a couple of cases where relayed messages are penalized
  (block times too far off, and hitting the free transaction relay limit).
  To be safe, I'll remove them. @p{»»}

  @p{««}As for relaying block headers for banned peers: "banned" means "if
  you try to connect to me I'll simply drop the connection attempt." I
  feel strongly that is the correct behavior; the motivation for the DoS
  prevention code is to "whitelist" peer behavior, and try to prevent
  possible 0-day attacks like "if I send you THIS invalid transactions
  followed by THAT sequence of weird bytes followed by THIS corrupted
  block header THEN I trigger an obscure bug in the version of OpenSSL
  that you're running and compromise your machine...." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1154}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-21 15:55:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45104.msg537757@s{hash}msg537757
@section 3 {tx}

  @p{««}RE: a be-safe thread for bitcoin: There are already a couple "be
  safe" threads stickied in the Bitcoin Discussion forum (e.g. the beware
  of trojan wallet stealers thread, the newbies article that links to
  keep-your-wallet-safe, etc). @p{»»}

  @p{««}Writing a more general one is not a bad idea; if I knew last
  November all the craziness that would happen this year I would have
  written one back then (but back then nobody was spending tens of
  thousands of dollars speculating on bitcoin). @p{»»}

  @p{««}RE: putting my employer in my forum signature: what do other people
  think? Would that be unfair advertising for TruCoin or good full
  disclosure? @p{»»}

  @p{««}If it drives more business to TruCoin then that will eventually,
  hopefully, mean more money in my pocket, so if it is up to me heck yeah
  I'll mention TruCoin in my signature! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1155}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-21 19:30:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45104.msg538128@s{hash}msg538128
@section 3 {tx}

  @p{««}I split this from "Be Safe" thread in Alternate Cryptocurrencies,
  and moved it here so more people could voice their opinions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1156}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-23 15:41:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg541446@s{hash}msg541446
@section 3 {tx}

  @p{««}Bitcoin version 0.4.0 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The main feature in this release is wallet private key encryption;
  @p{brk} you can set a passphrase that must be entered before sending
  coins. @p{brk} See below for more information; if you decide to encrypt
  your wallet, @p{brk} WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE
  LOCATION. If you @p{brk} forget or lose your wallet passphrase, you lose
  your bitcoins. @p{brk} Previous versions of bitcoin are unable to read
  encrypted wallets, @p{brk} and will crash on startup if the wallet is
  encrypted. @p{»»}

  @p{««}Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
  @p{brk} (bdb version 4.8) than previous versions (bdb 4.7). If you
  upgrade @p{brk} to version 0.4 and then revert back to an earlier
  version of bitcoin @p{brk} the it may be unable to start because bdb 4.7
  cannot read bdb 4.8 @p{brk} "log" files. @p{»»}

  @p{««}Notable bug fixes from version 0.3.24: @p{brk}
  

  @p{««}Fix several bitcoin-becomes-unresponsive bugs due to multithreading
  @p{brk} deadlocks. @p{»»}

  @p{««}Optimize database writes for large (lots of inputs) transactions
  @p{brk} (fixes a potential denial-of-service attack) @p{»»}

  @p{««}Wallet Encryption @p{»»}
  
  @p{««}Bitcoin supports native wallet encryption so that people who steal your
  @p{brk} wallet file don't automatically get access to all of your
  Bitcoins. @p{brk} In order to enable this feature, choose "Encrypt
  Wallet" from the @p{brk} Options menu. You will be prompted to enter a
  passphrase, which @p{brk} will be used as the key to encrypt your wallet
  and will be needed @p{brk} every time you wish to send Bitcoins. If you
  lose this passphrase, @p{brk} you will lose access to spend all of the
  bitcoins in your wallet, @p{brk} no one, not even the Bitcoin developers
  can recover your Bitcoins. @p{brk} This means you are responsible for
  your own security, store your @p{brk} passphrase in a secure location
  and do not forget it. @p{»»}

  @p{««}Remember that the encryption built into bitcoin only encrypts the
  @p{brk} actual keys which are required to send your bitcoins, not the
  full @p{brk} wallet. This means that someone who steals your wallet file
  will @p{brk} be able to see all the addresses which belong to you, as
  well as the @p{brk} relevant transactions, you are only protected from
  someone spending @p{brk} your coins. @p{»»}

  @p{««}It is recommended that you backup your wallet file before you
  @p{brk} encrypt your wallet. To do this, close the Bitcoin client and
  @p{brk} copy the wallet.dat file from ~/.bitcoin/ on Linux, @s{code}
  on Mac OSX, and
  @s{code} @p{brk} on Windows (that is @s{code} on @p{brk} Windows Vista and 7 and
  @s{code} on
  Windows XP). Once you have copied that file to a @p{brk} safe location,
  reopen the Bitcoin client and Encrypt your wallet. @p{brk} If everything
  goes fine, delete the backup and enjoy your encrypted @p{brk} wallet.
  Note that once you encrypt your wallet, you will never be @p{brk} able
  to go back to a version of the Bitcoin client older than 0.4. @p{»»}

  @p{««}Keep in mind that you are always responsible for your own security.
  @p{brk} All it takes is a slightly more advanced wallet-stealing trojan
  which @p{brk} installs a keylogger to steal your wallet passphrase as
  you enter it @p{brk} in addition to your wallet file and you have lost
  all your Bitcoins. @p{brk} Wallet encryption cannot keep you safe if you
  do not practice @p{brk} good security, such as running up-to-date
  antivirus software, only @p{brk} entering your wallet passphrase in the
  Bitcoin client and using the @p{brk} same passphrase only as your wallet
  passphrase. @p{»»}

  @p{««}See the doc/README file in the bitcoin source for technical details
  @p{brk} of wallet encryption. @p{»»}

  @p{««}Signed SHA1 checksums of the binary release files: @s{code} @p{»»}

  @p{««} Abraham Jewowich (1): @p{»»}

    @p{(li} Fix bug with accessing vchData(0) when vchData is empty. Fix
    typo in CBase58Data::CompareTo @p{li)}

  @p{««}Alex B (2): @p{»»}

    @p{(li} Romanian translation added @p{li)}

    @p{(li} Spanish translation update @p{li)}

  @p{««}Alex Waters (1): @p{»»}

    @p{(li} Updated readme file @p{li)}

  @p{««}Daniel Folkinshteyn (1): @p{»»}

    @p{(li} Update the list of seednodes. @p{li)}

  @p{««}Dawid Spiechowicz (1): @p{»»}

    @p{(li} added polish wallet encryption messages @p{li)}

  @p{««}Dean Lee (1): @p{»»}

    @p{(li} Update to the Chinese Simp translation @p{li)}

  @p{««}Dev Random (4): @p{»»}

    @p{(li} Linux gitian config with separate wxWidgets build @p{li)}

    @p{(li} Mingw gitian with separate wxWidgets and boost @p{li)}

    @p{(li} Mingw gitian build with deterministic bitcoin.exe by use of
    faketime @p{li)}

    @p{(li} Add Gitian Build descriptors for Boost and wxWidgets. @p{li)}

  @p{««}Doug Huff (1): @p{»»}

    @p{(li} Make mlock() and munlock() portable to systems that require
    the address to be on a page boundary. @p{li)}

  @p{««}Dylan Noblesmith (1): @p{»»}

    @p{(li} mlock() all private keys in memory @p{li)}

  @p{««}Eric Hosmer (1): @p{»»}

    @p{(li} Added crypter to makefile.vc. @p{li)}

  @p{««}Fabian H jr. (1): @p{»»}

    @p{(li} Updated checkpoints, maybe Tx fee should be reduced to 0.0001
    from 0.0005 and maximum minimum tx should be 0.0010. @p{li)}

  @p{««}Gavin Andresen (24): @p{»»}

    @p{(li} Do-nothing MapPort() ifndef USE_UPNP. fixes @s{hash}450 @p{li)}

    @p{(li} Don't std::advance past beginning of transactions array. Fixes
    @s{hash}465 @p{li)}

    @p{(li} Remove unused ScanMessageStart function @p{li)}

    @p{(li} Compile with DEBUG_LOCKORDER to detect inconsistent lock
    orderings that can cause deadlocks @p{li)}

    @p{(li} CHECKMULTISIG unit tests. @p{li)}

    @p{(li} Highlight mis-matching locks @p{li)}

    @p{(li} Fix rpc-hanging deadlocks @p{li)}

    @p{(li} Fixed potential deadlocks in GUI code. Also changed semantics
    of CWalletTx::GetTxTime(); now always returns the time the transaction
    was received by this node, not the average block time. And added
    information about -DDEBUG_LOCKORDER to coding.txt. @p{li)}

    @p{(li} Fix typo ("you own security") @p{li)}

    @p{(li} SetCrypted() obtains keystore lock, to be safe. @p{li)}

    @p{(li} Logic running with -keypool=0 was wrong (empty keys were being
    returned). Fixes @s{hash}445 @p{li)}

    @p{(li} Fix RPC call name in error message. @p{li)}

    @p{(li} obtain cs_wallet mutex to protect vchDefaultKey @p{li)}

    @p{(li} Fixed regression I introduced: wallets with lots of
    transactions were unusable in GUI. @p{li)}

    @p{(li} Fix bad merge: getaccountaddress was broken for new accounts
    @p{li)}

    @p{(li} Give hard-coded seed nodes a random last-seen time, to
    randomize order they're tried. @p{li)}

    @p{(li} Do not try to download blockchain from 0.3.23 nodes @p{li)}

    @p{(li} If compiled -DDEBUG_LOCKORDER and run with -debug, print out
    every mutex lock/unlock (helpful for debugging
    something-is-holding-a-mutex-too-long problems) @p{li)}

    @p{(li} Stay connected to seed nodes; disconnecting causes problems if
    you are trying to make the initial blockchain download. @p{li)}

    @p{(li} Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain
    downloads; avoid them @p{li)}

    @p{(li} Bumped version numbers to 0.4.0rc1 @p{li)}

    @p{(li} Optimize database writes for transactions with lots of TxIns.
    Patch from ArtForz, who discovered the problem. @p{li)}

    @p{(li} Fix AddAddress cs_mapaddresses/db transaction deadlock @p{li)}

    @p{(li} Fix QA email address @p{li)}

  @p{««}Giel van Schijndel (15): @p{»»}

    @p{(li} fix warning on 64bit systems: cast to pointer from integer of
    different size (-Wint-to-pointer-cast) @p{li)}

    @p{(li} fix warnings: expression result unused (-Wunused-value)
    @p{li)}

    @p{(li} fix warnings: using the result of an assignment as a condition
    without parentheses (-Wparentheses) @p{li)}

    @p{(li} fix warning: comparison of unsigned expression @p{lt} 0 is
    always false (-Wtautological-compare) @p{li)}

    @p{(li} fix warning: X enumeration values not handled in switch
    (-Wswitch-enum) @p{li)}

    @p{(li} fix warning: unused variable 'X' (-Wunused-variable) @p{li)}

    @p{(li} fix warning: unused function 'SigIllHandlerSSE2'
    (-Wunused-function) @p{li)}

    @p{(li} fix warning: variable 'nMinDepth' set but not used
    (-Wunused-but-set-variable) @p{li)}

    @p{(li} fix warning: control reaches end of non-void function
    (-Wreturn-type) @p{li)}

    @p{(li} Make some global variables less-global (static) @p{li)}

    @p{(li} Cleanup makefiles such that diffs to them are smaller @p{li)}

    @p{(li} Move func 'REF' from util.h to serialize.h @p{li)}

    @p{(li} Start moving protocol-specific code to protocol.(ch)pp @p{li)}

    @p{(li} Move CAddress to protocol.(ch)pp @p{li)}

    @p{(li} Move CInv to protocol.(ch)pp @p{li)}

  @p{««}Han Lin Yap (2): @p{»»}

    @p{(li} Comment "deprecated" @p{li)}

    @p{(li} Add a note to only include .po file @p{li)}

  @p{««}Jay Weisskopf (4): @p{»»}

    @p{(li} Add logos/branding currently found on bitcoin.org into NSIS
    installer. @p{li)}

    @p{(li} Set default compression for NSIS installer to LZMA. @p{li)}

    @p{(li} Remove NSIS branding from bottom divider. @p{li)}

    @p{(li} Increase resolution of Windows icon. @p{li)}

  @p{««}Jeff Garzik (8): @p{»»}

    @p{(li} Update CWallet::LoadWallet for proper return type. @p{li)}

    @p{(li} Bump version to 0.3.25 @p{li)}

    @p{(li} doc/README: word wrap into something readable @p{li)}

    @p{(li} CAddrDB::LoadAddresses: properly initialize CAddress @p{li)}

    @p{(li} src/makefile.unix: remove -DFOURWAYSSE2 @p{li)}

    @p{(li} Add reference python miner, in contrib/pyminer/ @p{li)}

    @p{(li} README.md: word wrap text file @p{li)}

    @p{(li} Revert "Define MSG_NOSIGNAL to 0 on platforms where it is
    unavailable." @p{li)}

  @p{««}Jeroenz0r (1): @p{»»}

    @p{(li} Translation from "Open Bitcoin" to "Verstuur Bitcoins" @p{li)}

  @p{««}JoelKatz (1): @p{»»}

    @p{(li} Fix UNIX-specific thread handle leak. @p{li)}

  @p{««}Johannes Henninger (1): @p{»»}

    @p{(li} Identify as "Bitcoin + version number" when mapping UPnP port
    @p{li)}

  @p{««}Luke Dashjr (7): @p{»»}

    @p{(li} Update nTime after nExtraNonce to avoid potential race
    (extraNonce being reset due to just-occurred time change after nTime
    is set) @p{li)}

    @p{(li} Reset extraNonce only every 15 seconds, just in case some
    miner is updating time himself and stuff @p{li)}

    @p{(li} Reset extraNonce only when prevBlock changes, so miners can
    continue updating the time on their work until it's stale @p{li)}

    @p{(li} Support for boost filesystem version 3 @p{li)}

    @p{(li} ignore stuff @p{li)}

    @p{(li} Save coinbase, not just extraNonce @p{li)}

    @p{(li} Bugfix: Use timestamp in coinbase rather than "bits", needed
    to ensure coinbase txn is unique even if address is the same @p{li)}

  @p{««}Matt Corallo (35): @p{»»}

    @p{(li} Add minversion to wallet. @p{li)}

    @p{(li} Add wallet privkey encryption. @p{li)}

    @p{(li} Set the number of SHA512 rounds based on the speed of the
    computer. @p{li)}

    @p{(li} Push unlocked_until in getinfo. @p{li)}

    @p{(li} Dynamically remove/insert the Options for encryption in the
    menus. @p{li)}

    @p{(li} Add the walletlock RPC method to lock the wallet manually.
    @p{li)}

    @p{(li} Add Wallet Encryption section to README @p{li)}

    @p{(li} Use DB Transactions when encrypting wallet. This speeds up the
    encryption process significantly. @p{li)}

    @p{(li} Make an invalid addrIncoming so that old clients crash.
    @p{li)}

    @p{(li} Update makefile.linux-mingw to work with crypter and UPnP fix.
    @p{li)}

    @p{(li} Fix makefile.linux-mingw @p{li)}

    @p{(li} Fix crashes when a wallet is locked and GetReservedKey() is
    called @p{li)}

    @p{(li} Generate Warning when using default key. @p{li)}

    @p{(li} Fix Build in GetReservedKey() in wallet.cpp @p{li)}

    @p{(li} Fix bad return values in LoadWallet. @p{li)}

    @p{(li} Actually use mapAlreadyAskedFor. @p{li)}

    @p{(li} Fix EncryptKeys crash introduced by a9ba4710, identified by
    TD. @p{li)}

    @p{(li} Check for duplicate txins in CheckTransaction. @p{li)}

    @p{(li} Make it clear that setting proxy requires restart to fully
    apply. @p{li)}

    @p{(li} Don't listen if on TOR (resolves @s{hash}441). @p{li)}

    @p{(li} Add missing include to serialize.h @p{li)}

    @p{(li} Add file for transaction tests. @p{li)}

    @p{(li} Cleanup test suite output to be more useful. @p{li)}

    @p{(li} Unify copyright notices. @p{li)}

    @p{(li} Missed a 'password' should be 'passphrase'. @p{li)}

    @p{(li} Fix incorrect RPC error messages @p{li)}

    @p{(li} Add specific wallet encryption details to doc/README @p{li)}

    @p{(li} Upgrade dependancies and tweak build process. @p{li)}

    @p{(li} Update binary mos to latest translations. @p{li)}

    @p{(li} Fix build process to actually work. @p{li)}

    @p{(li} Add binary mo for new translation. @p{li)}

    @p{(li} Update gitian build descriptors to produce proper builds.
    @p{li)}

    @p{(li} Update bitcoin icon to make nsis setup exe deterministic.
    @p{li)}

    @p{(li} Update binary mo to match latest po translation. @p{li)}

    @p{(li} Restructure gitian files and add download config files.
    @p{li)}

  @p{««}Michael Bemmerl (4): @p{»»}

    @p{(li} Basically some grammatical fixes of the German translation.
    @p{li)}

    @p{(li} Added German wallet encryption messages translation. @p{li)}

    @p{(li} Changed Russian translation according to comment in issue 395
    @p{li)}

    @p{(li} Updated German translation @p{li)}

  @p{««}Michal Zima (1): @p{»»}

    @p{(li} Updated czech translation @p{li)}

  @p{««}Nils Schneider (2): @p{»»}

    @p{(li} log low-level network messages only when fDebug is set @p{li)}

    @p{(li} missed printf in AbortMessage(); merged printfs in EndMessage
    @p{li)}

  @p{««}Patrick Varilly (1): @p{»»}

    @p{(li} Single DB transaction for all addresses in a message @p{li)}

  @p{««}Pieter Wuille (11): @p{»»}

    @p{(li} Prepare codebase for Encrypted Keys. @p{li)}

    @p{(li} Do not use obsolete CPrivKey for passing keys around @p{li)}

    @p{(li} Bugfix: add autogenerated addresses to address book @p{li)}

    @p{(li} get rid of mapPubKeys @p{li)}

    @p{(li} Use CBitcoinAddress instead of string/uint160 @p{li)}

    @p{(li} split off CBase58Data from CBitcoinAddress @p{li)}

    @p{(li} Fix for small change outputs @p{li)}

    @p{(li} Bugfix: don't overuse limited ExtractAddress @p{li)}

    @p{(li} avoid strAddress + validity checks @p{li)}

    @p{(li} SocketHandler thread can be detached @p{li)}

    @p{(li} Updated dutch translation @p{li)}

  @p{««}Stephane Gimenez (1): @p{»»}

    @p{(li} Single DB transaction for addresses from DNS seeds @p{li)}

  @p{««}Vegard Nossum (6): @p{»»}

    @p{(li} Add missing includes to key.h @p{li)}

    @p{(li} Add missing include to script.h @p{li)}

    @p{(li} Add missing includes to net.h @p{li)}

    @p{(li} Fix testing setup @p{li)}

    @p{(li} Add prototype for EvalScript() to script.h @p{li)}

    @p{(li} Add a file for script tests @p{li)}

  @p{««}Venkatesh Srinivas (4): @p{»»}

    @p{(li} Test for SO_NOSIGPIPE rather than assuming all BSDs support
    it. @p{li)}

    @p{(li} Qualify make_tuple with boost:: namespace. @p{li)}

    @p{(li} Use 'unsigned char' rather than 'char' for pchMessageStart.
    @p{li)}

    @p{(li} Define MSG_NOSIGNAL to 0 on platforms where it is unavailable.
    @p{li)}

  @p{««}Wladimir J. van der Laan (2): @p{»»}

    @p{(li} remove magic number: change threshold for nLockTime to
    constant @p{li)}

    @p{(li} make SetHash160 return a value (as specified in the function
    signature) @p{li)}

  @p{««}cjdelisle (1): @p{»»}

    @p{(li} wxWidgets needs to be at least version 2.9.1 because wallet
    crypto uses ToStdString() which is not in 2.9.0 @p{li)}

  @p{««}ovdeathiam (1): @p{»»}

    @p{(li} Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1157}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-23 15:42:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg541448@s{hash}msg541448
@section 3 {tx}

  @p{««}Oh, forgot to add: Thanks to everybody who helped out! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1158}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-23 16:54:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40593.msg541562@s{hash}msg541562
@section 3 {tx}

  @p{««}The 'open' command is the best way to run Bitcoin.app from the
  command line: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1159}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 00:09:16 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44423.msg542230@s{hash}msg542230
@section 3 {tx}

  @s{quotedtext}

  @p{««} Well, CPUs are easy-to-program general purpose hardware that can
  do lots of things (and several things at the same time, in these days of
  multicore CPUs) pretty darn fast. @p{»»}

  @p{««}GPUs are hard-to-program more-specialized hardware. These days they
  can do pretty much any raw calculation a CPU can do, faster@p{--} it
  just takes a lot more effort on the programmer's part to figure out how.
  That extra effort is only worthwhile for the most performance-critical
  code. @p{»»}

  @p{««}When I worked at Silicon Graphics I saw several interesting
  algorithms implemented using OpenGL operations reading and writing to
  texture memory and/or the accumulation buffer and/or the framebuffer.
  That was before OpenCL and GPU programming languages, but the experience
  gave me a lot of respect for the ability of good programmers to look at
  problems sideways and come up with ... interesting ... solutions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1160}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 00:24:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45391.msg542251@s{hash}msg542251
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've been wondering about that@p{--} is it possible to write a
  password cracker that generates all the lower-entropy passwords first?
  @p{»»}

  @p{««}That's the kind of theoretical computer science problem that it
  seems like should have an answer, or have a proof that it is equivalent
  to the halting problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1161}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 14:17:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg542809@s{hash}msg542809
@section 3 {tx}

  @s{quotedtext}

  @p{««}More details are in the doc/README file in the tree: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}L70@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1162}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 14:28:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg542820@s{hash}msg542820
@section 3 {tx}

  @s{quotedtext}

  @p{««} There is not a donation address for the whole development team; if
  there was, somebody would have to be in charge of keeping track of the
  bitcoins, deciding what they should be spent on, etc. @p{»»}

  @p{««}I don't want to be that somebody.... @p{»»}

  @p{««}If you like the wallet encryption feature, send bitcoins to: @p{»»}

    @p{(li}@p{(link}Matt Corallo@p{link)} :
  @s{code} and @p{(link}Jeff Garzik@p{link)} : @s{code} @p{»»}

  @p{««}Matt (aka "BlueMatt" in IRC) did the hard work of making wallet
  encryption happen, and deserves a ton of credit for being persistent and
  reworking @p{(so}his@p{so)} Jeff's initial implementation a few times
  based on feedback and suggestions. @p{»»}

  @p{««}Gregory Maxwell ('gmaxwell') also deserves credit and donations, he
  gave a lot of feedback and did a lot of testing: @p{»»}

    @p{(li}@p{(link}gmaxwell@p{link)} : @s{code}
    @p{li)}

  @p{««}(corrected to give Jeff credit for the initial implementation@p{--}
  sorry Jeff!)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1163}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 18:27:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg543096@s{hash}msg543096
@section 3 {tx}

  @s{quotedtext}

  @p{««} A real crash. @p{»»}

  @p{««}In a perfect world, Bitcoin version 0.1 would have included code
  that looked for a "Bitcoin version X or later required to read this
  wallet.dat file" setting, and notify the user and exit cleanly if X is
  greater than the version you're running. @p{»»}

  @p{««}We don't live in a perfect world. @p{»»}

  @p{««}So the second-best solution was to have version 0.4 and later do
  the "Bitcoin version X or later required to read this wallet.dat file"
  thing. And write a value into the wallet that causes previous versions
  of bitcoin to crash on startup. @p{»»}

  @p{««}If previous versions didn't crash when given an encrypted wallet,
  they'd just ignore the encrypted keys, generate a bunch of new,
  unencrypted keys, and give people heart attacks when they ran the old
  version of bitcoin and told them they had a 0 bitcoin balance. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1164}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-24 18:34:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=44858.msg543104@s{hash}msg543104
@section 3 {tx}

  @s{quotedtext}

  @p{««} I seem to recall (but am too lazy to look up) some interesting
  research on the gini coefficient for subgroups in the United States; if
  I recall correctly (and it is very likely I don't), Scandinavian
  Americans as-a-group have a lower gini coefficient than Scandinavians.
  @p{»»}

  @p{««}That is either evidence for economic oppression of underprivileged
  groups in the US, or evidence that culture matters when it comes to
  economic success, depending on whether you're left-leaning or
  right-leaning. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1165}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-25 01:30:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45523.msg543581@s{hash}msg543581
@section 3 {tx}

  @p{««}Encouraging people to expose their private keys makes me nervous.
  They're "private" for a reason, and it seems to me the vast majority of
  private keys will, a few years from now, either be stored on a secure
  device which is designed to never reveal them or will be split. @p{»»}

  @p{««}Why would a merchant "wish to accept typed or scanned Bitcoin
  private keys as payment" ? They're going to generate a transaction
  immediately anyway, it seems to me making a payment that way just opens
  up more potential ways of getting defrauded (e.g. merchant keeps the
  private key in case more bitcoins are ever sent to the same address, or
  merchant sends change to the same address and then a few days later uses
  the private key to take back the change). @p{»»}

  @p{««}I don't see any privacy or transaction-fee-saving advantages,
  either; am I missing something? @p{»»}

  @p{««}(I @p{(bf}do@p{bf)} see the usefulness of importing private keys
  into your wallet, that's a different feature that I'd like to be in the
  next release).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1166}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-26 15:57:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=15276.msg545514@s{hash}msg545514
@section 3 {tx}

  @p{««}I pulled Bitcoin-QT into the main bitcoin tree this morning. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1167}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-26 16:15:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45742.msg545547@s{hash}msg545547
@section 3 {tx}

  @p{««}I pulled Bitcoin QT into the master branch of @s{(link)} this
  morning. @p{»»}

  @p{««}See doc/readme-qt.rst for instructions on building Bitcoin QT.
  @p{»»}

  @p{««}And I updated doc/build-*.txt; they are now instructions for
  building bitcoind and don't mention wxwidgets at all. @p{»»}

  @p{««}There are still loose ends to tie up, like modifying the build
  scripts and the windows installer; I hope to tie those up in the next
  week or so, and have a release candidate for a version 0.5 available
  soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1168}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-26 19:18:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45564.msg545912@s{hash}msg545912
@section 3 {tx}

  @p{««}Very cool etotheipi. @p{»»}

  @p{««}Have you tried using mmap() to page the blockchain file into RAM
  instead of copying it explicitly? Operating systems are typically very
  well optimized for accessing mmap()'ed files. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1169}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-29 00:55:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45410.msg549544@s{hash}msg549544
@section 3 {tx}

  @p{««}Submit bugs here: @s{(link)} @p{brk} Although all of the GUI code
  is being replaced in the next version, so don't bother submitting UI
  bugs. @p{»»}

  @p{««}RE: debugging what bitcoin is doing in the 10 minutes it takes for
  the window to come up: @p{»»}

    @p{(li}@s{code} ... should tell you what
  it is busy doing. Probably loading the block chain and reading the
  wallet (do you have a very large wallet.dat?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1170}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-30 15:00:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46287.msg551670@s{hash}msg551670
@section 3 {tx}

  @p{««}Honestly, I don't think the future of bitcoin is running "heavy"
  nodes on our personal computers. @p{»»}

  @p{««}I think the vast majority of people will be using bitcoin through
  web or mobile apps in the not-too-distant future. So I'm not personally
  inclined to put a lot of effort into splitting the node and wallet,
  unless that makes creating lightweight web and mobile apps easier. @p{»»}

  @p{««}That said, the new QT gui does a much, much better job of letting
  you know what bitcoin is doing, both during initial startup and initial
  blockchain download. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1171}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-09-30 20:33:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=38928.msg552124@s{hash}msg552124
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, I want wallet security and backup as soon as possible, so I
  want transactions that support that functionality relayed and included
  in blocks as of the 0.5 release, if possible. @p{»»}

  @p{««}Current state: (old news for those of you on the
  bitcoin-development mailing list) @p{brk} I've made a PULL request for
  "standard" (a and b), (a or b), (a and b) or c transactions to
  eventually support keys split between different devices, wallet backup,
  and wallet-backup-with-split-keys. @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} Supporting lockTime or 2-of-3 escrow transactions or more generic
  'standard' transaction in the future is certainly possible. Put together
  a solid pull request that adds support for relaying/including in blocks,
  with unit tests and a testing plan and, assuming there's general
  consensus that what you're proposing is safe and secure and is near the
  top of the "will make bitcoin better" priority list, it will get pulled.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1172}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 00:26:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45211.msg553668@s{hash}msg553668
@section 3 {tx}

  @p{««}I'm going to shoot myself in my foot again thinking about stuff
  late in the day and week when my brain is tired... @p{»»}

  @p{««}... but here are some half-baked thoughts: @p{»»}

  @p{««}The: DUP HASH160 @p{lt}hash@s{gt} EQUALVERIFY that we're currently
  using to hash a 65-byte public key into a 20-byte bitcoin address could
  be generalized into something like: @p{»»}

  @p{««}n DIGEST160 @p{lt}hash@s{gt} EQUALVERIFY : create a secure 160-bit
  hash from the @p{lt}n@s{gt} items on the stack, make sure it matches a
  given hash. @p{»»}

  @p{««}That would be very useful for creating multisignature transactions
  where @p{lt}hash@s{gt} is really some arbitrary combination of public
  keys. @p{»»}

  @p{««}But it would be really spiffy if the complicated transaction could
  be in the ScriptSig (specified when the coins are spent) and not the
  ScriptPubKey (so the sender doesn't need to know what kind of
  transaction they're funding). Maybe something like: @p{»»}

  @p{««}ScriptPubKey: END_DIGEST160 @p{lt}hash@s{gt} EQUAL @p{»»}

  @p{««}... and the generic ScriptSig would be: @p{»»}

  @p{««}@s{code} ... an arbitrary script with public keys and CHECKSIGs
  and stuff.... @p{»»}

  @p{««}BEGIN...END_DIGEST160 would create a secure hash for all the
  opcodes and data between the begin and end. @p{»»}

  @p{««}I think I can convince myself that would always be secure. Concrete
  example of the simplest, one-key transaction would be: @p{»»}

  @p{««}ScriptSig: @p{lt}signature@s{gt} BEGIN_DIGEST160
  @p{lt}public_key@s{gt} CHECKSIGVERIFY @p{brk} ScriptPubKey:
  END_DIGEST160 @p{lt}hash@s{gt} EQUAL @p{»»}

  @p{««}Nobody can put another Script in the ScriptSig, because that would
  change @p{lt}hash@s{gt}. @p{brk} And the signature must be valid because
  it is checked in the ScriptSig. @p{»»}

  @p{««}If we're going to schedule a blockchain split to support new stuff,
  something like this seems like the right thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1173}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 01:10:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg553712@s{hash}msg553712
@section 3 {tx}

  @p{««}I like OP_EVAL better than BEGIN...ENDDIGEST. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1174}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 01:55:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46493.msg553778@s{hash}msg553778
@section 3 {tx}

  @p{««}The new QT GUI (in git HEAD) has a nifty
  block-chain-download-progress indicator. @p{»»}

  @p{««}I'd like to pull together a version 0.5 release candidate and start
  testing it early next week. @p{»»}

  @p{««}Maybe the big feature for version 0.6 can be fast initial download
  (I'm thinking the best thing to do for brand-new,
  starting-with-an-empty-wallet installations is to download only block
  headers, function as a 'lightweight' client, and 'backfill' full blocks
  until you're caught up with the full chain@p{--} then function as a
  'full' client). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1175}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 15:16:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46495.msg554318@s{hash}msg554318
@section 3 {tx}

  @p{««}-logtimestamps command-line param or logtimestamps=1 in the
  bitcoin.conf file. @p{brk} (I dont' remember when that option was added,
  a 'git blame util.cpp' will tell you, look for fLogTimestamps)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1176}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 15:45:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg554333@s{hash}msg554333
@section 3 {tx}

  @p{««}RE: be wary of OP_EVAL: @p{»»}

  @p{««}Agreed, we need to think hard about whether or not attackers could
  Do Evil Things like create an innocuous little script that pushed an
  infinite amount of data onto the stack or something (lets see...
  Serialized(@s{code} would do
  that...). Disallowing recursion (no OP_EVALs allowed in the OP_EVAL
  data) would, I think, prevent all of that mischief. @p{»»}

  @p{««}RE: OP_EVAL means no more IsStandard: I agree with ByteCoin. A
  ScriptSig would be IsStandard if it's ScriptPubKey was IsStandard, and
  if it's ScriptPubKey was the generic OP_EVAL form then the last value
  pushed by the ScriptSig would also have to pass the IsStandard test
  (deserialized into a Script). @p{»»}

  @p{««}RE: data should always be protected by a hash script: I think the
  answer is "don't be an idiot" and "use standard transaction types that
  have been banged on / thought through." @p{»»}

  @p{««}RE: sender/recipient negotiating a transaction: I think that may
  become the most common way of creating a transaction, but I don't think
  it will ever be the only way. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1177}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 15:48:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=45211.msg554335@s{hash}msg554335
@section 3 {tx}

  @p{««}I split ByteCoin's OP_EVAL post and followups @p{(link}into it's
  own thread@p{link)}. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1178}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 17:05:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg554416@s{hash}msg554416
@section 3 {tx}

  @s{quotedtext}

  @p{««} I agree. Security is really high on the priority list; I'd like to
  see secured bitcoin addresses in people's forum signatures within a
  year. I'm sure one of the alternate blockchains will take this idea and
  run with it, so much of the hammering-out will happen there. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1179}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 17:15:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43442.msg554429@s{hash}msg554429
@section 3 {tx}

  @p{««}Bugs can be reported via the github issues system: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... although the entire GUI is changing for the next release, so
  reporting GUI bugs like not being able to sort in the address book will
  be a waste of time. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1180}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-02 20:42:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg554620@s{hash}msg554620
@section 3 {tx}

  @p{««}Summary of a discussion @p{(link}that happened in IRC chat this
  afternoon@p{link)}: @p{»»}

  @p{««}There are 10 no-op opcodes that are explicitly for expansion: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}L150@p{link)} @p{li)}

  @p{««}They are currently enabled, and do nothing. @p{»»}

  @p{««}If we did the obvious thing and used one of them for OP_EVAL, then,
  surprisingly, OP_EVAL would not necessarily cause a block chain split.
  Why? @p{»»}

  @p{««}Old clients see: @p{»»}

  @p{««}Code: @p{lt}sig@s{gt} @p{lt}...serialized script...@s{gt} DUP
  HASH160 @p{lt}hash@s{gt} EQUALVERIFY OP_NOP1 New clients see: @p{»»}

  @p{««}Code: @p{lt}sig@s{gt} @p{lt}...serialized script...@s{gt} DUP
  HASH160 @p{lt}hash@s{gt} EQUALVERIFY OP_EVAL @p{brk} Old clients will
  consider the transaction valid as long as @p{lt}serialized_script@s{gt}
  hashes to the correct value and is not OP_FALSE, because a script
  evaluates as valid if it leaves a non-false value on the top of the
  stack when it is done. @p{»»}

  @p{««}New clients will do full validation: the hash has to be right AND
  the @p{lt}serialized script@s{gt} has to be valid (has to leave a
  non-false value on the top of the stack). @p{»»}

  @p{««}So: If upgraded clients and miners start producing transactions and
  blocks with OP_EVAL in them, they will be accepted by old clients and
  miners as valid. @p{»»}

  @p{««}That means OP_EVAL could be supported as soon as 50+% of the
  network hashing power upgraded, instead of requiring that 100% of the
  network (clients and miners) upgrade before a certain time or block.
  @p{»»}

  @p{««}Anybody want to volunteer to write a BIP that works through all the
  details? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1181}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-03 00:59:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46498.msg554857@s{hash}msg554857
@section 3 {tx}

  @s{quotedtext}

  @p{««} He did. He said ArtForz brought them up in the Alternative
  Currencies board. @p{»»}

  @p{««}See this thread for details: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}msg521772@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1182}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-03 01:28:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46498.msg554877@s{hash}msg554877
@section 3 {tx}

  @p{««}Fine, then ponder this for a while: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}msg517020@p{link)} @p{li)}

  @p{««}Executive summary: asymmetric difficulty adjustments and
  adjustments based on time are really, really hard to get correct. @p{»»}

  @p{««}I haven't thought about it hard, but I trust ArtForz when he says
  he thinks it is IMPOSSIBLE to get it right. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1183}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-03 13:43:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg555493@s{hash}msg555493
@section 3 {tx}

  @s{quotedtext}

  @p{««} So in an escrow situation all three parties have to exchange
  public keys and agree on one particular way of putting them together
  into a Script that they all agree on (so they all agree on the Script's
  hash). That seems OK@p{--} the three parties have to exchange public
  keys before creating any transactions in any case. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1184}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-03 14:10:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46498.msg555518@s{hash}msg555518
@section 3 {tx}

  @s{quotedtext}

  @p{««} First: sorry for conflating the off-by-1 and the asymmetric
  adjustment issues. As I said, I haven't taken the time to consider
  changing the bitcoin difficulty adjustment algorithm (too big a change
  for too little benefit, in my opinion; if we lose 90% of hashing power
  in a month then there that is a sign something much more serious is
  wrong with bitcoin than the difficulty algorithm; speculation on what
  will happen when the block reward drops seems pointless to me, I don't
  think we'll know until it happens). @p{»»}

  @p{««}Second: I've written 'discourage blocks' infrastructure: @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}(code reviews welcome) @p{li)}

  @p{««}... which should give us the ability to nudge miners to Do The
  Right Thing. Discouraging blocks that appear to be gaming the off-by-one
  bug should be enough incentive to prevent 50+% cartels from forming,
  without requiring a blockchain-splitting change.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1185}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-04 13:51:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg557083@s{hash}msg557083
@section 3 {tx}

  @p{««}Wow, so many great ideas! @p{»»}

  @p{««}RE: There is already code to warn the user if they are on a
  minority chain more than 6 blocks long@p{--} see GetWarnings(): @p{»»}

  @s{quotedtext}

  @p{««} It just warns, it doesn't stop you from generating/sending
  transactions. Perhaps if the longer fork is more than 120 blocks ahead
  it should. @p{»»}

  @p{««}ByteCoin: we can prevent the scenario you describe (generate a
  block with a NOP1/EVAL transaction whose validity is different in old
  and new clients) by: @p{brk} 1. Requiring that EVAL transactions be
  valid if the EVAL is interpreted as a no-op. New clients can replace
  EVALs with no-ops and re-evaluate them to make sure that is true.
  @p{brk} 2. Waiting until a majority of hashing power has upgraded before
  turning on EVAL. @p{»»}

  @p{««}gmaxwell: I really like the idea of implementing key recovery to
  save space in the block chain. It can also be done in a
  backwards-compatible way if only CHECKSIGs "hidden inside" of EVALs
  support it (CHECKSIG would be aware of whether it was being executed
  inside of an OP_EVAL, and if it was it could use a compressed version of
  the public key instead of the full public key). @p{»»}

  @p{««}All the ideas about figuring out what percentage of miners have
  upgraded: seems like that deserves its own discussion thread. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1186}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-04 14:35:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46498.msg557121@s{hash}msg557121
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. Who wants to volunteer? I'm too busy... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1187}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-05 18:11:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46927.msg558785@s{hash}msg558785
@section 3 {tx}

  @p{««}I voted no because of the fine-print in your original post. @p{»»}

  @p{««}I think setworkaux is OK, but I don't like "doesn't work on
  windows" changes to support one mining pool. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1188}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-05 18:21:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg558805@s{hash}msg558805
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... but isn't it the signatures that give each transaction its
  unique identity? I may be wrong, but without the signature hashes I
  think you can get two different transactions (two transactions that are
  exactly the same as far as scriptPubKeys, but spend different outputs)
  that hash to the same value, which would cause all sorts of problems,
  including replay attacks re-using old signatures. @p{»»}

  @s{quotedtext}

  @p{««} Interesting... too radical a change for right now, in my opinion.
  (I think Pieter's proposal is too radical a change for right now, too...
  I'm on the fence about whether OP_EVAL is too radical a change, but I
  think the advantages outweigh the risks). @p{»»}

  @s{quotedtext}

  @p{««} Pieter's proposal is @p{lt}signature+2bits@s{gt} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1189}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-06 14:16:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg560045@s{hash}msg560045
@section 3 {tx}

  @p{««}In an effort to keep discussion on track, I split the discussion of
  Lamport versus Bernstein signature schemes into its own thread. @p{»»}

  @p{««}So: can anybody think of any potential attacks that would be
  enabled by having a standard form: @p{»»}

  @p{««} Code: DUP HASH160 @p{lt}scripthash@s{gt} EQUALVERIFY OP_EVAL ...
  spent by providing: @p{»»}

  @p{««}Code: @p{lt}signatures@s{gt} @p{lt}serialized script@s{gt} @p{brk}
  The simplest @p{lt}serialized script@s{gt} would be @p{lt}pubkey@s{gt}
  CHECKSIG. @p{»»}

  @p{««} Things that occur to me or were brought up in the IRC discussion:
  @p{»»}

  @p{««} @p{(li}Denial-of-service if @p{lt}serialized script@s{gt} is
  allowed to contain OP_EVAL. @p{li)}

  @p{««}Proposal on the table is to completely disallow recursion, which
  eliminates that threat. I'm tempted to allow limited recursion (max 2
  levels deep maybe) because it would allow some really cool things to be
  done in the future.... @p{brk} @p{li)}

    @p{(li}Stealing coins because old miners/clients will not verify the
    signature hidden inside @p{lt}serialized script@s{gt}. @p{li)}

  @p{««}If 50+% of the hashing power on the network support OP_EVAL, then
  transactions that pass the @p{lt}scripthash@s{gt} check but fail the
  signature check inside the @p{lt}serialized script@s{gt} would be
  accepted as valid by old miners and clients, but would fail to confirm
  because they would be rejected by the majority of miners. @p{»»}

  @p{««}@p{(so}That CANNOT be used to trick exchanges or people using old
  software, because the old software will not recognize the new script
  form, and will simply ignore the transaction@p{--} you will
  @p{(bf}not@p{bf)} get "0/unconfirmed" OP_EVAL transactions displayed in
  old versions of Bitcoin.@p{so)} Wrong again! See casacius' excellent
  response. @p{brk} @p{li)}

    @p{(li}Creating or modifying @p{lt}serialized scripts@s{gt} @p{li)}

  @p{««}Maybe there's an attack waiting to happen because an attacker could
  trigger a buffer overflow bug by doing something like: @p{brk}
  @p{lt}safe serialized script@s{gt} 119 OP_ADD OP_EVAL @p{brk} But if
  there is a buffer overflow bug in an implementation's transaction script
  interpreter, then an attacker can almost certainly just send a "tx"
  message containing a non-OP_EVAL script that triggers the bug. OP_EVAL
  certainly does mean one more thing for an implementation to get right,
  but it isn't actually very hard to implement if you're already able to
  validate "tx" messages. @p{brk} @p{li)}

  @p{««}Any other attacks anybody can think of? If implementations are
  strict in which transaction forms they'll accept as "valid AND mine
  (counts towards my wallet balance)", but liberal in what transaction
  forms they'll accept as "valid, but I can't spend it" then it seems to
  me the risks are small. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1190}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-06 23:06:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg560805@s{hash}msg560805
@section 3 {tx}

  @s{quotedtext}

  @p{««} He wouldn't have included NOP1 through NOP10, either. @p{»»}

  @p{««}I file this under "Satoshi is a genius, part 9,432". It gives a
  smooth upgrade path using the same blockchain if ECDSA or SHA256 start
  to get fragile. @p{»»}

  @p{««}Attacking old clients by sending them coins with
  "will-never-be-satisfied-but-they-can't-tell-that" inputs
  @p{(bf}is@p{bf)} a concern@p{--} it is basically the Finney attack, but
  anybody will be able to try to pull it off and there is no time
  constraint. @p{»»}

  @p{««}However, I think the benefits of being able to send to a truly
  secure address @p{(bf}FAR@p{bf)} outweigh the risks, I don't think it
  will be difficult to get people to upgrade to a newer, more secure
  client, and accepting 0- or 1-confirmation transactions is always a bad
  idea. @p{»»}

  @p{««}I also think you're exaggerating the impact@p{--} OP_EVAL does not
  invalidate all of the security review that has been done so far,
  especially if the scripting language being EVAL'ed is unchanged from
  what we have today. @p{»»}

  @p{««}(PS: the latest git-head QT bitcoin contains a working bitcoin URI
  handler) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1191}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-07 12:41:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg561466@s{hash}msg561466
@section 3 {tx}

  @p{««}RE: 0-confirmation OP_EVAL transactions: @p{»»}

  @p{««}I think I'm doubly-wrong. @p{»»}

  @p{««}OP_EVAL transactions are non-standard to old clients, so they are
  dropped before being added to the memory pool. Old clients will not
  relay them, old miners that follow the IsStandard rules won't put them
  in blocks. @p{»»}

  @p{««}When a transaction comes in that depends on a transaction that is
  not in the block chain or memory pool, it is shunted into the orphan
  transaction pool, and isn't listed by listtransactions or show up in the
  GUI until all of its inputs are satisfied. @p{»»}

  @p{««}The risk would be a rogue miner putting invalid OP_EVAL
  transactions into blocks, which would trick old clients into showing
  transactions that depend on them as 0/ or 1/unconfirmed. @p{»»}

  @p{««} RE: "but bitcoin addresses are UGLY and the WRONG way to do it!"
  @p{»»}

  @p{««}Okey dokey. If I recall correctly, people were saying exactly the
  same thing about URLs 10 years ago (...google... @p{(link}yup@p{link)}).
  @p{»»}

  @p{««}If your argument is OP_EVAL is possibly insecure... it seems to me
  it is @p{(bf}much@p{bf)} easier to reason about the security of OP_EVAL
  than to reason about the security of URI schemes or schemes for passing
  around a transaction to be signed or using SIGHASH_ANYONECANPAY. @p{»»}

  @p{««}I agree that protocols for passing around either transactions or
  signatures are needed, I just don't think agreeing on what those
  protocols aught to be will happen anytime soon (how much you want to bet
  there will be a protocol buffers versus JSON debate that rages on for at
  least six months?) @p{»»}

  @p{««}RE: writing up a full design doc: I've always admired the IETF's
  "rough consensus and running code" approach to standards-making, so I'll
  be happy to write up a full design doc after I've got running code.
  Actually trying to IMPLEMENT multisignature transactions has taught me a
  whole lot about what will work in practice and what won't. @p{»»}

  @p{««} Finally, to try (in vain, probably) to focus discussion: The use
  cases I care about are: @p{»»}

    @p{(li} 1. A user running bitcoin on a device that gets infected by
    malware. I want them to be able to subscribe to some service that will
    provide transaction confirmation for any outgoing bitcoin transactions
    above a certain amount per day (like my bank does with my ATM card).
    @p{li)}

    @p{(li} 2. And I want them to be able to have a 'master wallet key'
    stored in physical form in their safe-deposit box so they can recover
    their wallet if they forget their passphrase or lose all their
    backups. @p{li)}

  @p{««}OP_EVAL appeals to me because I can see EXACTLY how to make those
  use-cases work with minor variations to the infrastructure we have today
  for performing bitcoin payments. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1192}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-07 23:19:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46485.msg562452@s{hash}msg562452
@section 3 {tx}

  @s{quotedtext}

  @p{««} Mmmm.... Twisted.... @p{»»}

  @p{««}I started defining a BitcoinProtocol class derived from
  twisted.internet.protocol.Protocol for my cross-implementation
  at-the-network-level testing project. I plan on using Twisted and Trial
  (the Twisted unit testing framework) to feed canned block-chains to
  "empty" nodes and make sure they Do The Right Thing (reject blocks that
  violate the blockchain rules or contain invalid transactions, accept
  blocks that contain weird-but-valid transactions, etc). @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Anyway, the BitcoinProtocol class might be a good place to start
  for anybody who wants to do some python-based bitcoin network
  programming. Good example to demonstrate is a little dump-blocks tool I
  wrote to spit out a blockchain in JSON format: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} (I'm a Twisted newbie, so improvements, suggestions, etc are very
  much appreciated)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1193}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-08 21:10:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47365.msg563812@s{hash}msg563812
@section 3 {tx}

  @p{««}Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
  Candidate 1 out, with a much-improved GUI. @p{»»}

  @p{««}Bad news: all the translations for the old wxWidgets Bitcoin are
  obsolete, and the process for making translations is different. @p{»»}

  @p{««}Is anybody willing to write new translations? Here's what you'll
  need to know: @p{»»}

  @p{««} @p{(li}Three translations already exist: de nl and ru.@p{li)}

    @p{(li}Translations are stored in ".ts" files in the
    @p{(link}src/qt/locale folder@p{link)}@p{li)}

    @p{(li}The '@p{(link}QT Linguist@p{link)}' tool can be used to create
    translations@p{li)}

    @p{(li}... or maybe an online tool like Transifex could/should be used
    to crowd-source the work@p{li)}

  @p{««}And is anybody willing to take the job of coordinating translation
  efforts, figuring out if Transifex is a good tool to use, and writing
  some documentation to make it easy for people to create and submit new
  translations? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1194}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-10 15:08:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46927.msg566290@s{hash}msg566290
@section 3 {tx}

  @p{««}This is why I don't pull additions or major changes to RPC commands
  without at least a couple of people looking at them and either saying
  "yup, that's exactly how I would do it" or "it'd be better if...." @p{»»}

  @p{««}I agree with Mike, the -coinbaser @p{lt}cmd@s{gt} should be
  separate from setauxwork. @p{»»}

  @p{««}Does setauxwork interact with the new getmemorypool RPC command at
  all? Should it? @p{»»}

  @p{««}And should there be a listauxwork RPC command? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1195}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-10 15:38:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46927.msg566316@s{hash}msg566316
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh? getmemorypool discussion is/was here: @s{(link)} @p{»»}

  @p{««}I'll just note that I'm damned if I do pull stuff that has some
  discussion here (and no objections raised), but damned if I don't pull
  stuff that first had no discussion, and then had a little discussion
  with some dissent.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1196}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-10 16:09:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47586.msg566342@s{hash}msg566342
@section 3 {tx}

  @p{««}I just tagged the git tree "v0.5.0rc1". If you are able, please
  compile and help test. @p{»»}

  @p{««}See the INSTALL file at the top of the source tree for instructions
  on compiling. Binary releases for at least unix and mac should be
  available in the next day or two (there is a show-stopper bug on
  Windows, and we could use help from people familiar with cross-compiling
  using mingw to update the Windows build process). @p{»»}

  @p{««}Major bugs you should be aware of: @p{»»}

  @p{««}@p{(link}Wallet does not relock on Win32@p{link)} @p{»»}

  @p{««}Major changes from version 0.4: @p{»»}

  @p{««}Switched from wxWidgets for the GUI to Qt, using Wladimir J. van
  der Laan's bitcoin-qt. Why? We didn't have any wxWidgets programmers
  contributing fixes or improvements. @p{»»}

  @p{««}New JSON-RPC commands: @p{»»}

  @p{««}getmemorypool : alternative to 'getwork' that provides everything
  needed to construct a block with a custom generation transaction.
  @p{brk} listsinceblock : Get all transactions in blocks since block
  (blockid) @p{brk} signmessage/verifymessage : sign/verify a message with
  a wallet public/private keypair @p{»»}

  @p{««}Deprecated JSON-RPC features: @p{brk} 'midstate' data item from
  getwork requests @p{»»}

  @p{««}Deprecated JSON-RPC commands that have been REMOVED: @p{brk}
  setlabel @p{brk} getlabel @p{brk} getaddressesbylabel @p{brk}
  getamountreceived @p{brk} getallreceived @p{brk} getreceivedbylabel
  @p{brk} listreceivedbylabel @p{»»}

  @p{««}Run: git shortlog @p{--}no-merges v0.4.0.. @p{brk} ... to get a
  complete list of changes, and thanks to everybody who is contributing!
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1197}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-10 20:39:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47586.msg566734@s{hash}msg566734
@section 3 {tx}

  @s{quotedtext}

  @p{««} Hmm? testnet accepts non-standard transactions today (I've been
  doing some experiments with multi-sig transactions on the testnet).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1198}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-10 22:45:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47501.msg566948@s{hash}msg566948
@section 3 {tx}

  @p{««}This forum is for "Technical discussion about Satoshi's Bitcoin
  client and the Bitcoin network in general. No third-party
  sites/clients..." @p{»»}

  @p{««}Would Open Transactions discussions be more appropriate in
  Off-Topic or Alternative Clients ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1199}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-11 13:34:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47352.msg567995@s{hash}msg567995
@section 3 {tx}

  @s{quotedtext}

  @p{««} kano, you seem to be under the mistaken impression that I am King
  of Bitcoin. @p{»»}

  @p{««}I told you that if you don't like the getmemorypool RPC method, you
  would need to gain consensus either on the Dev&amp;Tech section of these
  forums or the bitcoin-dev mailing list. That's how bitcoin works@p{--}
  rough consensus, not "submit requests to the King" or "petition the
  Central Committee." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1200}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-11 15:36:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47774.msg568199@s{hash}msg568199
@section 3 {tx}

  @s{quotedtext}

  @p{««} None taken. I've been trying pretty hard lately NOT to be The
  Central Authority, I don't want the job and I think the whole idea is
  contrary to the Zen of Bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1201}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-12 13:02:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47860.msg570043@s{hash}msg570043
@section 3 {tx}

  @p{««}I can't resist, the problem of how to bootstrap a new chain in the
  face of massive, hostile hashing power fascinates me. @p{»»}

  @p{««}CoinHunter, what will happen to SolidCoin if, God forbid, you get
  hit by a bus? What are the plans for the trusted CPF wallets? Do your
  heirs get control of them? @p{»»}

  @p{««}And what if SolidCoin is wildly successful@p{--} so successful that
  each SC is worth 1,000 euros? Will somebody still need 1 million of them
  (so have to be a euro billionaire) to be trusted? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1202}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-12 23:16:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=5024.msg571260@s{hash}msg571260
@section 3 {tx}

  @s{quotedtext}

  @p{««}Thinking out loud: @p{»»}

  @p{««}If miners (or other nodes) not relaying transactions starts to
  become an issue, "we" could write code to detect and discourage it.
  @p{»»}

  @p{««}Detecting: the node says it is a full node but you get many fewer
  'inv' messages from it compared to your other peers. @p{»»}

  @p{««}Discouraging: you refuse to relay or build on any new-block
  messages that you get from that node. @p{»»}

  @p{««}See @s{(link)} for a framework for the 'discourage' part. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1203}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-15 19:08:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47586.msg576631@s{hash}msg576631
@section 3 {tx}

  @p{««}Corrupting how? Did they install 0.5 and then downgrade (is it a
  backwards-compatibility issue)? @p{brk} Did it get corrupted when they
  encrypted? @p{brk} Anything interesting in their debug.log? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1204}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-16 18:43:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46370.msg577863@s{hash}msg577863
@section 3 {tx}

  @p{««}Nice work! @p{»»}

  @p{««}That's almost exactly the direction I'm heading with the
  cross-platform testing framework I've been working on, although I was
  planning on storing blocks in JSON format and was planning on using
  Python's Twisted/Trial framework to feed the different chains to the
  implementations to see if they accept or reject them. @p{»»}

  @p{««}I got sidetracked by the 0.5 release and then sidetracked again
  because I couldn't resist experimenting with the "OP_EVAL" idea and
  multisignature bitcoin addresses... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1205}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-16 19:21:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48340.msg577902@s{hash}msg577902
@section 3 {tx}

  @s{quotedtext}

  @p{««}Pass a 0 as the third argument to sendmany and it will send
  unconfirmed coins: @p{»»}

  @p{««}Code: sendmany @p{lt}fromaccount@s{gt} {address:amount,...}
  (minconf=1) (comment) 

# ----------------------------------------------------------------------
@section 2 {ms1206}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-17 14:24:35 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46370.msg579171@s{hash}msg579171
@section 3 {tx}

  @s{quotedtext}

  @p{««} I never started with bitcoinjs/nodejs, because I'm not a
  JavaScript programmer (and I'm too busy to take the time to learn).
  @p{»»}

  @p{««}It would be lovely if somebody who @p{(bf}is@p{bf)} a JavaScript
  programmer decided to show me how easy it would be and took
  bitcoinjs/nodejs and created a really nice cross-implementation testing
  framework with a bunch of test chains. @p{»»}

  @p{««}RE: Mike's point that creating full-difficulty test chains is a
  pain in the ass: I think that one-time pain is worthwhile, because I
  don't think we can count on every bitcoin implementor making it easy to
  run their implementation in a unit-test mode with super-low difficulty.
  And creating difficulty-1 blocks with a GPU is actually pretty darn
  quick... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1207}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-18 03:45:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48768.msg580488@s{hash}msg580488
@section 3 {tx}

  @s{quotedtext}

  @p{««} So... what would convince you? What if you could pay 10% of your
  expenses using bitcoin, and it cost you 1% less if you used bitcoin?
  @p{»»}

  @p{««}There are lots of chicken-and-egg problems that bitcoin has to
  overcome to compete with the dollars or euros we're all using now; I see
  two paths to bitcoin's success: @p{»»}

  @p{««}Maybe there are enough ideologically motivated people to form a
  self-sustaining economy. If even 1% of people find the idea of bitcoin
  attractive and started using it for 1% of their transactions that would
  still be huge. @p{»»}

  @p{««}Or maybe one or more 'killer apps' for bitcoin will emerge, giving
  it a foothold in certain markets. Maybe it will never expand beyond
  those markets, or maybe it'll slowly grow beyond them because of lower
  cost and higher tech. @p{»»}

  @p{««}If you're not excited by the idea of being an early adopter for
  what could be a massively influential idea, then you should probably
  come back in three or four years and either tell us "Told you it'd never
  work!" or join what should, by then, be a much more stable and
  easier-to-use system. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1208}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-18 03:55:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48718.msg580491@s{hash}msg580491
@section 3 {tx}

  @s{quotedtext}

  @p{««} Double-huh? You write your Mt.Gox account information on the
  deposit, Mt.Gox has all the information necessary to report to FinCen
  (because only upgraded Mt.Gox accounts can use the service) if required
  (if depositing more than whatever the daily/weekly FinCen requirements
  are, yada yada...). @p{»»}

  @p{««}What's up with the attitude Matthew? More ways to purchase bitcoin
  is a good thing... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1209}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-18 13:29:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48832.msg581044@s{hash}msg581044
@section 3 {tx}

  @p{««}What are you optimizing for? Ease of implementation? Wallet size?
  @p{»»}

  @p{««}Here's a naive implementation that I bet would work well in
  practice: @p{»»}

  @p{(li}  Sort potential inputs by priority (priority is @s{hash}confirmations *
  amount)  @p{li)}

  @p{(li}  Use the N highest-priority coins whose sum @s{gt}= amount needed
   @p{li)}

  @p{««}If you want to optimize for fragmentation and/or paying of fees,
  then also do: @p{»»}

  @p{(li}  If the change transaction is larger than some threshold amount,
  then split it in half (or maybe split it into Y change outputs, each of
  which is about the size of the threshold amount).  @p{li)}

  @p{(li}  If the change transaction is small and there are other
  small-valued/low-priority inputs available, add a few small-value inputs
  to merge them together.  @p{li)}

  @p{««}You could also optimize for privacy (try to avoid using more than
  one input and/or always create multiple change outputs), or tweak the
  above rules to try to always avoid fees... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1210}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-18 19:04:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48904.msg581653@s{hash}msg581653
@section 3 {tx}

  @p{««}Amir started the "get more formal about changes to bitcoin" ball
  rolling by creating @p{(link}BIP 0001@p{link)}, starting from the Python
  "PEP" / BitTorrent "BEP" processes. @p{»»}

  @p{««}The idea is to use BIPs for changes that may or will affect every
  bitcoin implementation (not to use them for proposed changes to one
  particular implementation). @p{»»}

  @p{««}I'd like to propose some minor changes to the process: @p{»»}

  @p{««} @p{(li}I propose that BIPs be wiki pages, with a social convention
  that the Author gets final word if any editing wars break out.@p{li)}

    @p{(li}If he's willing, I propose that Amir take the role of BIP
    editor.@p{li)}

    @p{(li}I think bitcoin is still too small to have a specialized
   "bitcoin-ideas" mailing list; I propose that new potential BIPs be
   discussed either here or on the bitcoin-dev mailing list.@p{li)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1211}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-18 21:43:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48904.msg581957@s{hash}msg581957
@section 3 {tx}

  @p{««}Example possible BIPs: @p{»»}

  @p{««}URL syntax for bitcoin payments @p{»»}

  @p{««}New OP_EVAL scripting opcode for receiver-specifies-transaction
  @p{»»}

  @p{««}New bitcoin address format to support OP_EVAL @p{»»}

  @p{««}(I'm actually working on those two) @p{»»}

  @p{««} Informational: @p{»»}

  @p{««}Process for announcing/scheduling/implementing a potentially
  block-chain-splitting change. @p{»»}

  @p{hrule}

  @p{««}You can browse through the PEP's at @s{(link)} to get some idea of
  the kinds of things that might be good BIPs; changes to the on-the-wire
  protocol to make blockchain downloads faster would certainly be
  appropriate.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1212}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-19 13:54:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg583037@s{hash}msg583037
@section 3 {tx}

  @s{quotedtext}

  @p{««} I pulled a Satoshi and decided to implement OP_EVAL to make sure
  it would actually work. @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Not ready for pulling, expect rebasing/tweaking/changing. But it is
  fully working on the testnet. @p{brk} (example transaction
  @p{(link}here@p{link)}) @p{»»}

  @p{««}The code puts "OP_EVAL" in the coinbase of generated blocks, so the
  rest of the network can see how many miners support it. @p{»»}

  @p{««}I gathered contact information for the top ten mining pools last
  week; when there is rough consensus on the details, I'll contact them to
  see if they have concerns and/or are willing to support OP_EVAL. @p{»»}

  @p{««}I started writing up BIPs for the various pieces of OP_EVAL, I'll
  post them soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1213}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-19 19:20:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg583615@s{hash}msg583615
@section 3 {tx}

  @p{««}Draft BIPs, comments very welcome: @p{»»}

  @p{««}@s{(link)} @p{brk} @s{(link)} @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1214}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-19 21:04:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg583802@s{hash}msg583802
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. Although there might be a way of accomplishing the same thing
  without recursion: @p{»»}

  @p{««}Use case: @p{»»}

  @p{««}Imagine we want, in the future, to support "this" OR "that"
  transactions. Where "this" and "that" are themselves possibly complex
  multisignature or escrow or whatever transactions. @p{»»}

  @p{««}Most straightforward way might be a new standard transaction that
  looks like: @p{»»}

   @s{code}

  @p{««} IF @p{»»}

    @p{(li}OP_EVAL "evaluate the this" @p{li)} ELSE @p{brk} DUP HASH160
  @p{lt}hash160@s{gt} EQUALVERIFY @p{brk} OP_EVAL "... or evaluate the
  that" @p{brk} ENDIF @p{»»}

  @p{««} So you'd redeem it by putting one script or the other on the stack
  (along with the signatures needed by the script). @p{»»}

  @p{««}So.... maybe you want to recurse so that the IF/ELSE script is
  @p{(bf}itself@p{bf)} part of a standard, single-hash OP_EVAL, so you can
  use a newfangled bitcoin address to send to it. That would look like:
  @p{»»}

   @s{code}

  @p{««} scriptPubKey: DUP HASH160 @p{lt}hash of IF/ELSE script@s{gt}
  EQUALVERIFY OP_EVAL @p{»»}

  @p{««} I am NOT proposing an IF/ELSE "this or that" standard script type;
  I think there is plenty of enough work to do to actually make secure
  wallets and in-the-chain escrow work. But supporting limited recursion
  for non-standard or future transactions seems easy and safe... @p{»»}

  @p{««}(terminology footnote: calling scriptSig+scriptPubKey
  "transactions" isn't accurate, the transaction is the bigger thing, but
  I'm not sure what else to call them; I hope y'all follow what I'm
  saying)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1215}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-20 01:17:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46538.msg584239@s{hash}msg584239
@section 3 {tx}

  @p{««}I don't know nuthin about error-detecting checksums, but I think
  the time it would take to implement it and argue about it would be
  better spent on more user-friendly, secure ways of making bitcoin
  payments. I haven't heard of even a single case of "I manually typed in
  a bitcoin address and the coins got lost because I made an undetected
  transposition error." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1216}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-24 22:51:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47586.msg591906@s{hash}msg591906
@section 3 {tx}

  @s{quotedtext}

  @p{««} You == me? @p{»»}

  @p{««}There's a sticky here about creating a pull request, it'd be most
  excellent if you could make you==you and fix the doc/readme-qt.rst file.
  @p{»»}

  @p{««}I'll try hard to remember to mention this for the 0.5 release
  notes, but I'll warn you I'm really good at forgetting things.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1217}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-25 01:30:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49764.msg592118@s{hash}msg592118
@section 3 {tx}

  @p{««}Thanks to Amir for agreeing to be the "BIP editor" and getting
  these up: @p{»»}

  @p{««}@s{(link)} @p{brk} @s{(link)} @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1218}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-25 01:46:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49686.msg592138@s{hash}msg592138
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, but if you are spending a lot of time or effort trying to
  make money on an essentially unproductive activity then I think you
  should ask yourself if there's something else you could be doing that
  would be more effective at making the world a better place. @p{»»}

  @p{««}I think a lot of buy-low-sell-high, there-is-always-a-bigger-fool,
  or high-frequency trading fits into the "isn't making the world a better
  place" category. If you're competing for a bigger slice of a fixed-sized
  pie, I think you should think hard about what you could do instead to
  make the pie bigger for everybody. @p{»»}

  @p{««}Mmmm.... pie...... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1219}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-25 18:54:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49826.msg593004@s{hash}msg593004
@section 3 {tx}

  @p{««}I think Casascius did the right thing. @p{»»}

  @p{««}He has no way of knowing how many people got the phishing email,
  and no other way of contacting people who might fall for the scam. @p{»»}

  @p{««}If you're upset because you have to poke the 'delete' button on
  your email one extra time... then I think you're overreacting. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1220}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-25 20:13:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49841.msg593117@s{hash}msg593117
@section 3 {tx}

  @p{««}Bitcoin is revolutionary because it is decentralized, with no
  single point of control or failure. @p{»»}

  @p{««}However, over the last six months or so it has become obvious to me
  that the rest of the world isn't set up to interact with a radically
  decentralized system like Bitcoin, and I think forming a not-for-profit
  organization will be a positive step towards Bitcoin's long-term
  success. @p{»»}

  @p{««}I'm posting this to see if there is a consensus on what a Bitcoin
  Foundation should be. @p{»»}

  @p{««}To get the conversation started, here are some functions I think a
  Bitcoin Foundation could perform: @p{»»}

  @p{««} @p{(li}Interact with the legal system, where a centralized entity
  is needed: for example, to hold the Bitcoin trademark, own/control the
  bitcoin.org domain name, etc. @p{li)} @p{li)}

    @p{(li}Act as a central library for accurate information about
  Bitcoin, so journalists and policymakers have an 'official' place to
  learn about Bitcoin. @p{li)} @p{li)}

    @p{(li}Collect donations to fund infrastructure necessary for
  Bitcoin's growth (organize regular developers' conferences or
  get-togethers maybe? pay for development of cross-implementation testing
  tools? pay core developers' salaries? create a certification/testing
  program for Bitcoin implementations? create a central clearinghouse for
  information about legal issues surrounding Bitcoin across the world?)
  @p{li)} @p{li)}

  @p{««}Other not-for-profit organizations that could be emulated: @p{»»}

  @p{««} @p{(li}The Anti-Phishing Working Group (the APWG's chairman, David
  Jevans @s{(link)}, is willing to help make a Bitcoin Foundation happen).
  @p{li)} @p{li)}

    @p{(li}The Tor Project @p{li)} @p{li)}

    @p{(li}The Apache Software Foundation @p{li)} @p{li)}

  @p{««}Are there others that work well, or are there examples of what NOT
  to do? Assuming there is rough consensus that a Bitcoin Foundation is a
  good idea, I would like to get something imperfect up and running
  quickly, with the expectation that it will evolve over time.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1221}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-25 22:29:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49841.msg593329@s{hash}msg593329
@section 3 {tx}

  @s{quotedtext}

  @p{««}Depends on who "we" is and what corporate form the Foundation
  takes... @p{»»}

  @p{««}... but the one of the first orders of business will be more
  discussions with lawyers who know about those types of things.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1222}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-26 20:44:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49854.msg594889@s{hash}msg594889
@section 3 {tx}

  @p{««}I hate to be a wet blanket, but if "they" wanted to stop this why
  couldn't "they" simply pass a law stating that it was illegal to buy or
  sell bitcoins? @p{»»}

  @p{««}Or "they" could impose a punitive tax on purchases or sales of
  bitcoins. @p{»»}

  @p{««}I suppose my point is: if "they" @p{(bf}really@p{bf)} want to make
  bitcoin illegal, then they will find a way to do it; I don't think
  creating bitcoin derivatives will help much on the legal front. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1223}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-27 03:00:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=39471.msg595325@s{hash}msg595325
@section 3 {tx}

  @p{««}I've been thinking a lot about transaction IDs and how to gather
  signatures for multi-party transactions, too. @p{»»}

  @p{««}For the most part, I think all the details should normally be
  hidden from users@p{--} I think "Select Transaction Type" is much too
  geeky. @p{»»}

  @p{««}Thinking out loud, and starting with what I think will be a very
  common use case: buyer and seller and somebody to resolve disputes that
  arise (2-of-3 escrow). @p{»»}

  @p{««}Are you imagining all three are using a bitcoin client? In my head,
  one might be using bitcoin-qt, another a web-based wallet service, and
  the dispute resolution would be done by a company with a website. I
  don't think "we're all running bitcoin on our computers" will be the
  common case. @p{»»}

  @p{««}So here's how I see it working (my ClearCoin experience may be
  biasing me): @p{»»}

  @p{««}Buyer and Seller sign up with the escrow service. During signup,
  they each give the escrow service a public key. How? @p{»»}

    @p{(li}@p{--} Clunky way: they poke a "Advanced.... New Public Key"
    button and then copy&amp;paste a long string of hex @p{li)}

    @p{(li}@p{--} Better way: they poke a link on the escrow status page
    that does some magic @p{li)}

    @p{(li} (maybe there's a
    @p{(link}bitcoin:sendnewpublickey?destination=@s{(link)}@p{link)} URI
    type that can be made to Do the Right Thing) @p{li)}

  @p{««}Buyer or Seller then creates an escrow at the escrow service's
  website. @p{»»}

    @p{(li}@p{--} Escrow service creates or assigns a keypair for their
    part of the 2-of-3 @p{li)}

    @p{(li}@p{--} Escrow service creates a newfangled bitcoin address
    using the 3 public keys. @p{li)}

  @p{««}Buyer sends bitcoins to the newfangled bitcoin address (by clicking
  on it at the escrow service's page@p{--} it could be a bitcoin:... link)
  @p{»»}

  @p{««}Escrow service's wallet sees the payment to the newfangled bitcoin
  address, updates the status page. @p{»»}

  @p{««}Buyer tells seller they paid. Seller checks the escrow status page,
  clicks on a "send me the money" link and ships the product to the buyer.
  @p{»»}

  @p{««}What does the "send me the money" link do? It needs to get a
  signature from the seller for a transaction that spends from the 2-of-3
  transaction and sends to the seller's wallet. Another bitcoin: URI that
  does magical stuff?
  (@p{(link}bitcoin:signtransaction?tx=...hex...@p{link)}&amp;destination=@s{(link)}
  ) Or some other clunky copying-and-pasting of long hex strings? @p{»»}

  @p{««}Days later: Buyer gets the product and is happy. They visit the
  escrow status page and click on a "send THEM the money" link, which does
  more magical stuff. Or more clunky copying-and-pasting of hex strings.
  In any case, the escrow service gets the second signature and sends the
  transaction to the bitcoin network, and the coins show up in the
  seller's wallet. @p{»»}

  @p{««}@p{hrule} @p{brk} Couple of notes: @p{»»}

  @p{««}I don't see the newfangled-bitcoin-address being part of the
  @p{(so}buyer's or@p{so)} seller's wallet, and adding it to their wallet
  would be yet another step. @p{»»}

  @p{««}Need to think about what happens if the escrow service suddenly
  disappears... they can't steal any coins, but if neither buyer nor
  seller knows the public key the escrow service is using then they can't
  complete the transaction by themselves. Perhaps the bitcoin: URI that
  the buyer uses to fund the transaction should include all the public
  keys and should be added to the buyer's wallet... @p{»»}

  @p{««} @p{hrule} @p{brk} All of this would be much nicer if there was a
  more user-friendly, security-friendly representation of bitcoin
  addresses / public keys. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1224}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-27 03:21:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49889.msg595350@s{hash}msg595350
@section 3 {tx}

  @p{««}Here's my public key, or you can fetch it from the MIT pgp
  keyserver. Or it is linked on the bitcoin.org homepage. @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1225}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-28 18:32:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50159.msg597702@s{hash}msg597702
@section 3 {tx}

  @p{««}Quick update on why there is no final 0.5 release out yet: @p{»»}

  @p{««}Short answer: because I'm really paranoid about bitcoin binary
  builds, and the switch to Qt means a change in the way the builds are
  done. @p{»»}

  @p{««}Long answer: @p{»»}

  @p{««}Linux builds should be all set; the 'gitian' trusted build process
  works nicely. @p{»»}

  @p{««}Windows builds are being difficult; we need a gcc expert to help
  debug the 'gitian' cross-compile (see @s{(link)} ). @p{»»}

  @p{««}Unless somebody steps forward and says "I'll support compiling
  bitcoin-qt/bitcoind with Visual Studio) I'm going to remove
  src/makefile.vc and make sure the readmes say that only the mingw
  toolchain is supported. @p{»»}

  @p{««}Mac builds were slightly broken for the 0.4 release (they don't run
  on OSX 10.5@p{--} you need 10.6 or greater). I'm "recompiling the world"
  to hopefully fix that, and hope to have mac binaries available soon (let
  me know if you can help test, especially if you have a 32-bit Intel mac
  running 10.5). @p{»»}

  @p{««}On my wish list for builds (anybody want to volunteer?): @p{»»}

  @p{««}I think it'd be spiffy to have a .pro file to compile bitcoind;
  maintaining N different makefiles is annoying and error-prone. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1226}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-28 19:05:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=39471.msg597752@s{hash}msg597752
@section 3 {tx}

  @p{««}RE: BIP 0010 : Cool! @p{»»}

  @p{««}Suggestion: if we're going to borrow PGP's file format, then we
  should be as compatible as possible, and reference their standards
  document: @s{(link)} @p{»»}

  @p{««}In particular, they use Radix64 encoding, not hex... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1227}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-29 02:53:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50206.msg598296@s{hash}msg598296
@section 3 {tx}

  @p{««}I was just thinking today about resetting the -testnet with new
  rules to make it more stable/useful... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1228}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-29 03:08:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg598309@s{hash}msg598309
@section 3 {tx}

  @p{««}I'm starting this thread to brainstorm rule changes for -testnet
  and talk about a possible testnet reset for the next release. @p{»»}

  @p{««}The testnet isn't currently usable, because hashing power on it is
  unpredictable. Difficulty shoots up because somebody decides to throw
  lots of machines at it, then they leave and it takes MONTHS for
  difficulty to drift back down. @p{»»}

  @p{««}Here's a shot at hair-brained rules for the testnet: @p{»»}

  @p{(li}  Fix the difficulty at 1.0, no matter how many people are mining.
   @p{li)}

  @p{(li}  Clients reject new blocks with timestamps more than 1 minute
  different from their time (implies: you have to have an accurate system
  clock to play with the other nodes on the testnet, otherwise you'll be
  on your own fork).  @p{li)}

  @p{(li}  Clients reject new blocks if their timestamp is less than 2
  minutes after the previous best-block's timestamp.  @p{li)}

  @p{(li}  Clients prefer to build on blocks that include more memory-pool
  transactions, instead of taking first-block-they-receive.  @p{li)}

  @p{««}Goals behind those rules: @p{»»}

    @p{(li}Always easy to mine @p{li)}

    @p{(li}Limit block-chain growth (max 1 new block every 2 minutes)
    @p{li)}

  @p{««}So: could a griefer make life miserable for the rest of us under
  those rules? What would happen if there were five or six people with a
  fair bit of hashing power all trying to mine as fast as possible on
  testnet? (lots of block chain splits, I think, but that's probably just
  fine on testnet) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1229}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-10-31 17:36:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg601350@s{hash}msg601350
@section 3 {tx}

  @p{««}Auto-reset once a month... very interesting idea. @p{»»}

  @p{««}It'd make a mess of peoples' testnet wallets@p{--} they'd be full
  of orphaned 0-confirmation transactions. But deleting your testnet
  wallet once a month wouldn't be that big a burden, and that should
  prevent people from trading testnet coins as if they were worth
  something. @p{»»}

  @p{««}Somebody who wanted to be annoying could still drive up difficulty
  after every reset and make life miserable for anybody testing their new
  exchange or merchant software, though. @p{»»}

  @p{««}The problem with @p{(bf}just@p{bf)} doing more frequent difficulty
  adjustments is somebody with lots of hashing power can still over-write
  huge parts of the chain whenever they like. I suppose you could argue
  that bitcoin services should be written so that they can handle suddenly
  getting a 600-block-long chain-reorg... but that just does NOT happen on
  the real bitcoin network. @p{»»}

  @p{««}More hare-brained thoughts: could automatic block-chain lock-ins
  for the testnet be implemented somehow? Fetch a block depth/hash pair
  from a website somebody volunteers to create (auto-updated once a
  day...) ? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1230}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-01 17:25:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50558.msg602608@s{hash}msg602608
@section 3 {tx}

  @s{quotedtext}

  @p{««} One million percent is a 10,000 times rise in price. @p{brk} The
  first trades on bitcoinmarket.com were at a price of something like
  0.001 US dollars; 10,000 times that would be $10, and lots of bitcoins
  traded over $10 earlier this year. @p{»»}

  @p{««}So I think the Fool got it right.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1231}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-01 17:40:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50159.msg602625@s{hash}msg602625
@section 3 {tx}

  @p{««}Another quick update: @p{»»}

  @p{««}Wladimir figured out what was breaking the Win32 cross-compiled
  builds (one of the 'hardening' gcc flags is apparently busted for
  mingw32 cross-compiles), so Linux and Win32 binaries of a rc2 should be
  available soon. @p{»»}

  @p{««}Yet another hurdle was thrown in my way by Mother Nature Saturday
  night; we got over a foot of snow, and my house and home office still
  have no power. Mac builds won't be available until my main machine has
  power... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1232}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-01 17:55:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50523.msg602648@s{hash}msg602648
@section 3 {tx}

    @p{(li} 1. TxOut scripts are not evaluated until they are spent@p{--}
    those are probably unspendable TxOuts. @p{li)}

    @p{(li} 2. The inputs must be valid (you're looking at coinbase txns
    with no inputs though). Again, TxOuts aren't evaluated until they are
    used as inputs in another transaction; as long as they deserialize
    properly they'll be accepted. @p{li)}

    @p{(li} 3. I don't know of any other bugs in the scripts ops, but I
    don't know that anybody has written thorough unit tests for them
    (anybody looking for a good get-your-feet-wet project that could be a
    good one to tackle; there are already unit tests for CHECKMULTISIG in
    the repostitory....). @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1233}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-01 19:06:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg602756@s{hash}msg602756
@section 3 {tx}

  @s{quotedtext}

  @p{««} What were you testing that you needed to dedicate about a month of
  multi-GH mining effort? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1234}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-01 21:37:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50523.msg602973@s{hash}msg602973
@section 3 {tx}

  @s{quotedtext}

  @p{««} See src/test/script_test.cpp in git HEAD. @p{brk} Or for more
  examples of testing script operations, the unit tests I wrote here:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1235}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-02 12:42:57 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50616.msg603693@s{hash}msg603693
@section 3 {tx}

  @p{««}Anybody know why it says I found a block? I am not mining...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1236}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-02 19:56:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg604435@s{hash}msg604435
@section 3 {tx}

  @p{««}I just sent this email to several of the top mining pools; I'm also
  putting it here to get wider feedback from "the mining community": @p{»»}

  @p{««}@p{hrule} I'm writing to the top mining pools to see if you will
  support Bitcoin Improvement Proposals 11, 12, and 13: @p{brk} @s{(link)}
  @p{brk} @s{(link)} @p{brk} @s{(link)} @p{»»}

  @p{««}I think they are critical to making Bitcoin more secure for people
  who have never heard of GPG or AES. They don't solve the wallet security
  problem, but they put in place low-level mechanisms that will allow
  higher-level services that DO solve the "computer virus stole my
  bitcoins" problem. Once multi-signature transactions are supported by
  the network, Bitcoin wallets can be coded to contact "Wallet Protection
  Services" to get a second signature/authorization before coins can be
  spent (details of exactly how the Wallet Protection Service and the
  client communicate will be in future BIPs). They will also make it
  possible to create escrow services that cannot spend the bitcoins in
  escrow among other interesting use cases. @p{»»}

  @p{««}This same feature might be used to keep your pool's bitcoin
  balances more secure, also@p{--} you could run your own Wallet
  Protection Code on a separate machine that (perhaps) required manual
  intervention before providing a second signature on pool payouts if some
  unusual payout activity was occurring because somebody managed to break
  your security and get access to the pool's wallet. @p{»»}

  @p{««}I'm proposing extreme caution rolling out support for
  multi-signature transactions, and, especially, supporting the OP_EVAL
  feature that allows more secure bitcoin addresses@p{--} and that is why
  I'm asking you whether or not you're willing to patch your mining pool
  software sometime in the next two months to support the new 'standard'
  @p{brk} transaction types. @p{»»}

  @p{««}I've already written an implementation for Bitcoin 0.5 that will
  soon become a PULL request. @p{»»}

  @p{««}The new features are backwards-compatible with existing miners and
  clients, but we do have to be careful when rolling out OP_EVAL because
  an attacker could create non-standard transactions and try to split the
  block-chain. @p{»»}

  @p{««}Here is the timeline I've proposed in BIP 0012 : @p{»»}

  @p{««}Now until Jan 15, 2012 : miners update their software, start
  including CHECKMULTISIG and OP_EVAL transactions in blocks they mine,
  and indicate support by including the string "OP_EVAL" in the blocks
  they produce. @p{»»}

  @p{««}Jan 15, 2012: we assess support for the new feature by looking at
  the percentage of blocks that contain "OP_EVAL". If a majority of miners
  are not supporting it, then deployment will be delayed or cancelled (a
  setting in bitcoin.conf controls the switchover date, with the default
  being Feb 1, 2012). @p{»»}

  @p{««}Feb 1, 2012: assuming there was majority support on Jan 15, OP_EVAL
  is fully supported/validated. @p{»»}

  @p{hrule}
  
  @p{««}Questions I have for you: @p{»»}

  @p{««}Is there anything I can do to make it easier for you to support
  these new features? For example, would patches against an earlier
  version of bitcoind be useful? (if so, what version?) @p{»»}

  @p{««}Is the timeline reasonable? @p{»»}

  @p{««}Questions you might have: @p{»»}

  @p{««}What happens if you don't support these new transaction types but a
  majority of other miners do? @p{»»}

  @p{««}If you do not put non-standard transactions in your blocks, then
  nothing will happen. @p{»»}

  @p{««}If you DO put non-standard transactions in your blocks, then you
  would be vulnerable to an "invalidate blocks under the new rules"
  attack, where somebody sends you a transaction that is valid under the
  old interpretation of the OP_EVAL opcode (which is a no-op) but not
  valid under the new rules. Your miner would put that transaction in
  blocks that you mine, and all of your blocks would be rejected by the
  majority of miners. @p{»»}

  @p{««}What happens if you DO support these new transaction types but a
  majority of other miners do not? @p{»»}

  @p{««}All transactions that you put into blocks will be valid under both
  the old rules and the new rules, so there is no danger that blocks you
  create will be rejected by the network. There IS a danger that the rest
  of the network will accept a block under the old rules that you consider
  invalid under the new rules; that is why I am proposing that we evaluate
  acceptance of the new rules on January 15. @p{»»}

  @p{««}Can you support one of the BIPs but not all of them? @p{»»}

  @p{««}Yes@p{--} supporting CHECKMULTISIG as a standard transaction type
  (BIP 11) can safely be deployed right now, there is no danger of a
  block-chain-split, etc. @p{»»}

  @p{««}BIPs 12 and 13 will let users (or mining pools) use short bitcoin
  payment addresses to have bitcoins go directly into secure,
  multi-authentication-required-to-spend wallets. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1237}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-02 20:45:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50523.msg604524@s{hash}msg604524
@section 3 {tx}

  @p{««}OP_0 pushes an empty array of bytes onto the stack, so you should
  @s{code}. @p{»»}

  @p{««}(thanks go genjix for setting me straight, I'd been thinking OP_0
  pushed a 0x00 onto the stack, and that isn't right. The scripting engine
  knows that an empty array is 'False', and FIPS standards make sure
  hashing empty strings/arrays is well-defined...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1238}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-02 20:57:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50523.msg604556@s{hash}msg604556
@section 3 {tx}

  @p{««}OP_1 through OP_16 push single bytes (0x01 through 0x10) onto the
  stack. @p{»»}

  @p{««}RE: updating the wiki: good idea, I'll go do that... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1239}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-03 14:36:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49764.msg605381@s{hash}msg605381
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good question. The timeline for clients is less critical, as long
  as a majority of hashing power will properly interpret OP_EVAL clients
  that relay/generate those transactions can be rolled out anytime after
  Feb 1. @p{»»}

  @p{««}So I'd suggest releasing a 0.5.something or 0.6 after the Jan 15
  "are the big miners on board" evaluation that turns on OP_EVAL support
  Feb 1. @p{»»}

  @s{quotedtext}

  @p{««} Same time. @p{»»}

  @s{quotedtext}

  @p{««} Another very good question. The timestamp in the block will be
  used to determine whether OP_NOP1s in the block are interpreted as
  no-ops or OP_EVAL when checking block validitity (wall-clock GMT time
  will be used to figure out if the node should relay/mine OP_EVAL
  transactions). I'll double-check my code, I think I did NOT code it that
  way. @p{»»}

  @s{quotedtext}

  @p{««} That seems exceedingly unlikely; once the big mining pools switch,
  there is a very strong incentive for the smaller pools to switch, too.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1240}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-03 14:46:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49764.msg605391@s{hash}msg605391
@section 3 {tx}

  @s{quotedtext}

  @p{««} The beauty of OP_EVAL is it is backwards-compatible with old
  merchants/users/vendors/miners; there is no reason to require that they
  all switch over at the same time, they can continue to operate with
  their old software for as long as they like (assuming all this happens,
  there will be increasing pressure over time for them to upgrade so they
  can pay to newfangled BIP 13 bitcoin addresses). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1241}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-03 15:45:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg605448@s{hash}msg605448
@section 3 {tx}

  @s{quotedtext}

  @p{««}Great! @p{»»}

  @s{quotedtext}

  @p{««} Unless Mike messed up his implementation of the OP_NOP1 and made
  it do something other than be a no-op, there should be no problem
  (OP_EVAL re-defines OP_NOP1 to do stuff instead of doing nothing, but
  all OP_EVAL transactions are valid if the OP_EVAL is interpreted as a
  no-op). @p{»»}

  @s{quotedtext}

  @p{««} Publish how? I already made a couple of testnet transactions using
  OP_EVAL; I will make a few on main net (assuming Luke doesn't change
  Eligius to reject OP_NOP1 transactions). And I wrote thorough unit tests
  that create valid/invalid OP_EVAL transactions. @p{»»}

  @s{quotedtext}

  @p{««}What do you mean by "everytime there's a block change" ? @p{»»}

  @s{quotedtext}

  @p{««}"OP_EVAL" can be anywhere in the coinbase, I'll probably write a
  little tool using bitcointools to look at OP_EVAL adoption over time
  will make sure it doesn't care where the string appears. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1242}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-03 21:28:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50778.msg605836@s{hash}msg605836
@section 3 {tx}

  @p{««}I'd like to see one or more of the alt chains take: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and start supporting OP_EVAL, multisignature transactions, and
  the new bitcoin address type. @p{»»}

  @p{««}(and thanks to coblee- he (she?) did help flesh out the ideas)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1243}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-03 21:37:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50791.msg605847@s{hash}msg605847
@section 3 {tx}

  @p{««}0.5.0 is next; just working out the last build/deploy issues now...
  @p{»»}

  @p{««}A day or two after a release is final I always bump the third
  version number, so somebody running "git head" (the latest source code)
  has a newer version number. So there @p{(it}was@p{it)} a 0.4.1 that was
  never released; the switch to Qt for the graphical UI was a big enough
  change to justify a jump to version 0.5 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1244}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-04 21:10:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50778.msg607071@s{hash}msg607071
@section 3 {tx}

  @s{quotedtext}

  @p{««}See BIP 12, the Backwards Compatibility section, for gotchas@p{--}
  block chain forks are possible if you're not careful. They won't happen
  by accident, but if you assume there is an attacker that just wants to
  cause inconvenience by forking the chain then you have to roll-out the
  change carefully. @p{»»}

  @p{««}To test on testnet: @p{»»}

  @p{««}Apply the patch. Then use the extended 'validateaddress' RPC
  command that is part of the patch to get public keys for several of your
  bitcoin addresses (use getnewaddress to generate new ones if you need
  to). @p{»»}

  @p{««}Combine those public keys into multi-signature addresses using the
  new addmultisig RPC command: @p{»»}

    @p{(li} addmultisigaddress @p{lt}nrequired@s{gt}
    @p{lt}'("key","key")'@s{gt} (account) @p{li)}

  @p{««}So for a 2-of-3 escrow you'd call: @p{»»}

    @p{(li} addmultisigaddress 2
    '("...pkey1...","...pkey2...","...pkey3...")' @p{li)}

  @p{««}It returns a multisignature bitcoin address. @p{»»}

  @p{««}You'd do that on all the machines involved in the escrow
  transaction. @p{»»}

  @p{««}To fund that multisignature address, you just use the normal
  sendtoaddress (or sendmany or sendfrom) RPC commands, using the address
  returned from addmultisigaddress. @p{»»}

  @p{««}To spend those funds... more patches are needed. You CAN actually
  spend them if you have ALL the private keys in your wallet; if you do,
  then the multisignature transaction is treated just like any other
  transaction you've received, and will show up as part of your wallet's
  balance, in listtransactions output, etc. @p{»»}

  @p{««}Modifying the patch so that you can spend them if you have
  @p{lt}nrequired@s{gt} keys is probably the right thing to do, although
  the security implications of that for shared-wallet providers needs to
  be carefully thought through. And in almost all of the real
  multisignature use cases, a RPC calls to create and sign
  partially-signed transactions is the right thing to do, NOT importing
  private keys from the other people involved in the transaction. See:
  @s{(link)} and @s{(link)}@s{hash}msg597785 for a proposal on how to do that.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1245}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-04 21:24:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg607083@s{hash}msg607083
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm proposing one new RPC command: 'addmultisigaddress' ... that
  combines several public keys into one BIP 13 -style newfangled bitcoin
  address. @p{»»}

  @p{««}You get the public keys from the 'validateaddress' RPC command,
  which I've extended to give the full public key if you give it one of
  your bitcoin addresses. @p{»»}

  @p{««}I extended the 'send*' RPC commands so they know how to send to the
  newfangled bitcoin addresses, and can send coins you received as
  multisignature transactions if you hold all the corresponding private
  keys (listtransactions will also show you them, getbalance counts them
  in your balance, etc). So yes, anybody can generate new transactions to
  test... @p{»»}

  @p{««}Alan Reiner is proposing BIP 10 as the 'real' way to get
  multisignature transactions signed and spent: @s{(link)} @p{brk} (no
  implementation yet, as far as I know). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1246}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-06 17:55:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49888.msg608705@s{hash}msg608705
@section 3 {tx}

  @s{quotedtext}

  @p{««} Let me think... a problem that affects a small number of people...
  means you end up with 8 connections instead of more than 8... and has an
  easy, obvious workaround... and if fixed will be difficult to test
  thoroughly... @p{»»}

  @p{««}Not high on my priority list. @p{»»}

  @p{««}Things that ARE high on my priority list: @p{»»}

  @p{(li}  Getting the 0.5 release out the door  @p{li)}

    @p{(li}@p{(li} Improving initial startup and block download times
    @p{li)} @p{(li} Solutions for wallet security and backup @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1247}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-07 18:45:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51141.msg609721@s{hash}msg609721
@section 3 {tx}

  @p{««}If you can, please help sanity test Bitcoin 0.5 release candidate 3
   binaries: @p{brk} @s{(link)} @p{»»}

  @p{««}Files and checksums are: @p{»»}

  @s{code}

  @p{««} Linux and Windows binaries are created using the
  gitian-trusted/reproducible-build tool; the OSX binary was built by me.
  @p{»»}

  @p{««}I'll be writing up release notes this afternoon; assuming no
  'show-stopper' bugs are found, these binaries will be the 0.5 release.
  @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1248}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-07 20:49:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51203.msg609874@s{hash}msg609874
@section 3 {tx}

  @p{««}I purchased this laptop: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... to do Bitcoin 'gitian' builds. It's a perfectly good laptop,
  runs nicely, but I'm re-selling it because its Core Duo CPU can't do
  64-bit builds. @p{»»}

  @p{««}Specs are: @p{»»}

    @p{(li}1.83 Mhz Core Duo processor @p{li)}

    @p{(li}120GB memory @p{li)}

    @p{(li}2G disk @p{li)}

    @p{(li}Wifi @p{li)}

  @p{««}Running Ubuntu 11.04, includes laptop, battery and power supply.
  @p{»»}

  @p{««}Asking 50 BTC, I'll pay shipping anywhere in the US; if I don't get
  any takers here, I'll re-auction it on Ebay on Friday, Nov 11. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1249}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-07 21:28:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51141.msg609927@s{hash}msg609927
@section 3 {tx}

  @s{quotedtext}

  @p{««} Have you tried running rc3 on W2k? I don't have a W2k machine to
  test on (I did sanity test rc2 on XP SP3), but I don't know of any
  reason it would fail. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1250}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-08 14:03:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51232.msg610603@s{hash}msg610603
@section 3 {tx}

  @p{««}This would be a good bitcoin.stackexchange.com question. @p{»»}

  @p{««}Do what deepceleron says... although you might want to copy JUST
  the two blk*.dat files (you don't need addr.dat or the database/
  subdirectory).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1251}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-09 22:30:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8091.msg612493@s{hash}msg612493
@section 3 {tx}

  @p{««}No issues with export wallets/private keys. I share gmaxwell's
  concerns about making it easy to shoot yourself in the foot, but most of
  us are grown-ups and if you're talking using the RPC interface there are
  already plenty of ways to shoot your feet. @p{»»}

  @p{««}Remove private key I had issues with, because if you're using the
  'accounts' feature then removing keypairs from a wallet (and their
  associated transactions) does unpredictable things to account balances.
  At the very least, I think it should tell you what effects it had. Maybe
  a JSON result that tells you how account balances changed, e.g. @s{code}
  That way, if it had an unexpected
  effects you would know to restore the wallet from backup. @p{»»}

  @p{««}And it seems like 'sweep private key' and 'merge wallets' is really
  the functionality most people want, not import private key/wallet keys.
  The only issue I have with them is they are slow because of the
  rescanning of the block chain, and they may not work or may not be
  secure if you don't happen to have the whole block chain downloaded.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1252}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-10 14:24:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=30200.msg613246@s{hash}msg613246
@section 3 {tx}

  @s{quotedtext}

  @p{««} @s{(link)} @p{brk} Start with dumpblocks.py @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1253}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-10 17:06:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51474.msg613442@s{hash}msg613442
@section 3 {tx}

  @p{««}Discussing how to fix this in IRC now. @p{»»}

  @p{««}This @p{(bf}IS@p{bf)} a show-stopper issue for the 0.5 release.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1254}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-11 21:57:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51604.msg615237@s{hash}msg615237
@section 3 {tx}

  @p{««}A serious bug was been found in the "encrypt wallet" function of
  bitcoin versions 0.4 and 0.5: private keys may be left unencrypted in
  the wallet.dat file after encryption. @p{»»}

  @p{««}If your encrypted 0.4 wallet file is stolen, an attacker may be
  able to recover some or all of your private keys and steal some or all
  of your bitcoins. @p{»»}

  @p{««}The development team has been working on fixes for bitcoin versions
  0.4 and 0.5, but it will take at least a few days to test them
  thoroughly. Until they are available, you should assume that your
  'encrypted' wallets are as vulnerable as an unencrypted wallet, and
  follow all the best practices for keeping them safe (see @p{(link}here
  for a list@p{link)}). @p{»»}

  @p{««}It is embarrassing and astonishing that this critical a bug was not
  caught before the 0.4 release; constructive suggestions on how to
  improve the testing and release processes that do not assume access to
  hundreds of thousands of dollars of funds to hire security consultants
  or QA teams are welcome. Getting sufficient testing of code BEFORE it is
  released has been a chronic problem for this project. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1255}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-12 00:00:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51604.msg615405@s{hash}msg615405
@section 3 {tx}

  @s{quotedtext}

  @p{««}That's not quite right@p{--} you need to exhaust all of the keys in
  your 'key pool' to be safe, so you'd have to ask for 101 new keys. @p{»»}

  @p{««}Part of the fix is marking all of the keys in the keypool as used.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1256}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-12 16:46:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51604.msg616027@s{hash}msg616027
@section 3 {tx}

  @s{quotedtext}

  @p{««} Luke-Jr is planning on supporting 0.4-based releases (finding
  somebody to fix wxWidgets-related bugs is an issue, though). @p{»»}

  @p{««}The issue I have with calling any pre-1.0-release 'stable' is it
  implies a level of maturity that I don't think we're at yet. I can see
  1-year develompment-@s{gt}unstable-@s{gt}stable release cycles once
  we're at a solid Bitcoin 1.0 release that I can actually feel
  comfortable recommending to my non-geek relatives. @p{»»}

  @p{««}My fear is that developers would happily code away and use the
  development branch, bugs would pile up against the unstable branch (and
  would get ignored because developers were happily coding away on dev,
  and nobody really wants to do bug fixing or QA testing), and unstable
  would never become stable enough to tag 'stable.' But I've never led an
  open source software project before, so I might very well be wrong (best
  way to convince me is to point to other small open source projects that
  we can emulate@p{--} I don't think emulating big projects like Ubuntu
  will work). @p{»»}

  @p{««}I agree that when a fix has been tested and is available an alert
  to the affected versions is a good idea. @p{»»}

  @s{quotedtext}

  @p{««}Unfortunately, TruCoin ran into a funding crunch because an
  investor got cold feet and had to stop paying for anything besides
  directly-related-to-TruCoin work. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1257}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-12 17:30:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51474.msg616068@s{hash}msg616068
@section 3 {tx}

  @p{««}Code review and testing for the proposed fix is welcome: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Here's how I tested: @p{»»}

  @p{««}I dumped private keys from an unencrypted wallet (using
  bitcointools). @p{»»}

  @p{««}I wrote a little tool that took a list of private keys and a
  filename and reported whether or not the 32-bytes of any of the private
  keys appears anywhere in the file. @p{»»}

  @p{««}I also hacked a copy of bitcoin to dump any newly-generated-private
  keys into debug.log before they are encrypted and written to disk. @p{»»}

  @p{««}I verified that new keys for an encrypted wallet are never written
  to any of the Berkeley DB database files by encrypting the wallet,
  invalidating all of the existing keypool keys, generating new, encrypted
  keypool keys, sending bitcoins to a new, encrypted key, and checking all
  of the files for any unencrypted copies of the new private key. @p{»»}

  @p{««}So the problem became how to deal with old, previously-unencrypted
  keys that were ending up in the wallet.dat file. @p{»»}

  @p{««}I hoped that telling Berkeley DB to 'compact' the file would remove
  the 'slack' space that contained the old data (the root of the problem
  is BDB doesn't actually completely delete/overwrite data when you delete
  a key/value pair; if I missed a setting that makes it do that, please
  let me know). Doing that reduced the number of old private keys found by
  my tool, but didn't eliminate the problem. @p{»»}

  @p{««}Pieter worked on a different solution in parallel@p{--} completely
  rewriting the database to a new file when encryption is turned on, then,
  assuming the rewrite succeeds (we trust BDB to do what a database is
  designed to do@p{--} reliably write data to the disk), replace the old
  wallet.dat with the new wallet.dat.rewrite. During that process, all
  keypool keys are marked as 'used' (which actually means just not writing
  a 'pool' entry for them in wallet.dat.rewrite). @p{»»}

  @p{««}That works@p{--} no old private keys made it into the new
  wallet.dat. @p{»»}

  @p{««}But during testing I ran into two issues: @p{»»}

  @p{««}1) The wallet.dat file isn't the only place the old private keys
  were found; the database transaction log (database/log.000..N) and some
  of the __db.00N files also contained them. Adding a call to remove() the
  database environment at shutdown fixed the __db.00N issue; I had to
  write code to remove the database/log.000..N file on clean shutdown.
  @p{»»}

  @p{««}2) If more wallet database operations were performed after the
  rewrite (I had written code to top-up the keypool with new, secure keys
  before locking the wallet), old private keys could end up in the new
  wallet.dat. @p{»»}

  @p{««}To fix both of those issues, we modified the code so that a
  shutdown happens after wallet re-encryption. @p{»»}

  @p{««}... which reminds me of something else I need to test: if you
  startup with a wallet encrypted by bitcoin versions 0.4.0 or 0.5.0, the
  wallet is re-encrypted and all of your old keypool keys are considered
  used. (I believe it does not shutdown after doing that, though, but it
  should) @p{»»}

  @p{««} @p{hrule} We've never made any guarantees that unencrypted private
  keys will not end up on your hard disk; if you have a virus on your
  system that can directly read blocks off your hard disk then it can
  almost certainly also read system memory, and could steal your wallet
  passphrase the first time you sent bitcoins. @p{»»}

  @p{««}Filling up free space on your disk (as suggested in this thread)
  might work, but it is a much better idea to send all of your bitcoins to
  new, 'born-encrypted' keys. Once fixed binaries are available, that will
  be easy@p{--} just upgrade and then send all of your bitcoins to
  yourself, using newly-generated addresses. @p{»»}

  @p{««}@p{hrule} Suggestions for more radical solutions, like storing
  private keys in a separate file, are out of scope. We got what we got; I
  personally think that a really good "deterministic private keys"
  solution, where the private keys for your wallet are derived from a
  passphrase that is only in your head (and maybe written down and stored
  in your safe deposit box) would be a better use of developer time rather
  than reworking how we store private keys on disk. @p{»»}

  @p{««}Even better would be further work on multisignature/multidevice
  solutions so even if your private keys are compromised an attacker can't
  spend your coins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1258}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-14 18:51:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51425.msg618403@s{hash}msg618403
@section 3 {tx}

  @s{quotedtext}

  @p{««}Huh what? Version 0.5 supports drag-and-drop of bitcoin: URIs. And
  there's a pull request pending for click-to-pay support. @p{»»}

  @s{quotedtext}

  @p{««} One fear is bitcoin-address-rewriting malware, like the
  URL-rewriting phishing malware we have today. Actually, combining the
  two would be very effective (direct the user to a phishing site where
  all the bitcoin: URIs pay or donate to the scammers). We need better
  ways users can be certain they are paying who they think they are
  paying.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1259}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-14 21:28:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51425.msg618609@s{hash}msg618609
@section 3 {tx}

  @s{quotedtext}

  @p{««}You mean the wiki page that describes an overly-complicated scheme
  with your pet feature that nobody else likes (hexadecimal amounts)?
  @p{»»}

  @p{««}And that we're all ignoring because we don't feel like getting into
  wiki editing wars with you (see the history from 9 May)? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1260}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-15 14:09:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51712.msg619395@s{hash}msg619395
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, I've been busy. Although I have in the past said that I'm
  worried about long-term incentives for relaying transactions (and am not
  worried at all about the block reward dropping and being replaced by
  fees). @p{»»}

  @p{««}I skimmed the paper, and I'm really pleased to see very smart
  people thinking hard about the incentive structures built-in to Bitcoin.
  I think most people see all the digital signatures and peer-to-peer
  networking technology but miss that much of the brilliance of Bitcoin is
  how the incentives are designed. @p{»»}

  @p{««}Overall, I think the paper is most valuable as a demonstration of
  how to @p{(it}prove@p{it)} that a particular solution to the problem
  could work@p{--} whether or not the particular solution the authors
  propose (rewarding the relaying nodes) is the "best" solution I'm not
  sure @p{--} there are lots of dimensions of 'goodness' here @p{--}
  lowest cost, fastest transaction confirmations, easiest to implement,
  most compatible with the network we have now, etc. @p{»»}

  @p{««}A while ago I proposed another potential solution: have relaying
  clients drop their connection to 'greedy' nodes. If you have a node that
  sends you new blocks but isn't relaying you new transactions, maybe drop
  your connection to it and ban it's IP address from re-connecting to you
  for a while. Or maybe don't relay (or relay after delaying a couple of
  minutes) new-block messages that you first see from that node. The idea
  is that a mild dis-incentive should be sufficient to encourage nodes to
  do the right thing and relay all valid transactions and blocks. @p{»»}

  @p{««}Figuring out "isn't relaying you new transactions" in a spoof-proof
  way would be a little tricky@p{--} you want to see real transactions,
  not miner-generated "I'm pretending to be a good network citizen"
  transactions. A scheme where you relay transactions to half of your
  peers and then monitor the other half to see if you receive the
  transaction back from them should work to detect nodes that are relaying
  many-fewer-than-normal transactions or blocks. @p{»»}

  @p{««} @p{hrule} @p{brk} I've also said repeatedly in the past I'd like
  to see more diversity in the networks used to transmit bitcoin
  transactions/blocks (with bridges between them so we're all working on
  the same block-chain). There doesn't have to be just one right answer to
  this problem, and I would love to see people simulate or experiment with
  variations on the existing network protocol or radically different
  protocols. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1261}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 16:03:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg620607@s{hash}msg620607
@section 3 {tx}

  @p{««}I've uploaded release candidate binaries for Bitcoin versions 0.4.1
  and 0.5.0 to SourceForge: @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The 0.4.1 release is the old wxWidgets-based Bitcoin with a
  critical fix to the wallet encryption feature. @p{brk} The 0.5 release
  is the new Qt-based Bitcoin (which also includes the wallet encryption
  bugfix). @p{»»}

  @p{««}Report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1262}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 16:48:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg620654@s{hash}msg620654
@section 3 {tx}

  @s{quotedtext}

  @p{««} To be absolutely sure, you need to extract your private keys and
  then run a tool to look for them in your wallet.dat file (or other files
  on your disk). @p{»»}

  @p{««}If you are able to compile a custom version of bitcoin and run
  python, here's how: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}If you can't compile a custom version of bitcoin or run python
  code, then you'll have to trust other people to thoroughly test. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1263}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 18:40:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg620783@s{hash}msg620783
@section 3 {tx}

  @s{quotedtext}

  @p{««}Fixed, thanks for finding it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1264}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 22:43:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52024.msg621059@s{hash}msg621059
@section 3 {tx}

  @p{««}bitcoind follows the JSON-RPC-over-HTTP spec for reporting errors,
  but it sounds like Sergio's library follows a different spec. You're not
  the first person to complain that bitcoind returns HTTP error codes;
  here's a one-line patch to change that behavior with a
  "-rpcerrorstatus=200" argument/option: @p{»»}

  @s{code}

  @p{««} Let me know if that solves the problem and/or if it causes any
  other issues; if it doesn't, I'll submit it as a PULL request. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1265}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 22:52:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52035.msg621075@s{hash}msg621075
@section 3 {tx}

  @p{««}Neither of those addresses are valid according to my bitcoind:
  @p{»»}

   @s{code}

  @p{««} The checksum in addresses is 4 bytes, so there is a
  one-in-four-billion chance that a random typo would get you a valid
  address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1266}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-16 23:55:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52035.msg621130@s{hash}msg621130
@section 3 {tx}

  @p{««}D'oh! I was running a -testnet bitcoind.... @p{»»}

  @p{««}Never mind.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1267}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-17 05:15:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52049.msg621389@s{hash}msg621389
@section 3 {tx}

  @s{quotedtext}

  @p{««} You might want to set up a testnet-in-a-box environment, so you
  can pretty easily create blocks yourself to get transactions confirmed
  quickly: @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1268}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-17 05:18:16 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52059.msg621392@s{hash}msg621392
@section 3 {tx}

  @p{««}Good idea.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1269}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 15:12:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52196.msg622947@s{hash}msg622947
@section 3 {tx}

  @p{««}I had grand plans to make this the center of a Linux-powered
  multimedia center... but after doing nothing with it for a couple of
  months I think I just won't ever have the time. @p{»»}

  @p{««}@s{image} @p{brk} This is an Intel Atom D410 -powered little
  computer, with 1GB of memory and a 250GB hard disk, running a custom
  version of Linux (easily upgraded to the latest Ubuntu or other Linux
  distro by booting from a USB stick, though). @p{»»}

  @p{««}Like new in the original box with all the original parts (keyboard,
  mouse, stand, power cable). @p{(link}New at Amazon: $229@p{link)} @p{»»}

  @p{««}Selling for 90 BTC, I'll pay shipping to the US or Canada. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1270}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 16:58:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52196.msg623039@s{hash}msg623039
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, VGA out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1271}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 18:10:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg623132@s{hash}msg623132
@section 3 {tx}

  @p{««}Updated to release candidate 6: @p{brk} @s{(link)} @p{brk}
   @s{(link)} @p{»»}

  @p{««}Two changes were made between rc5 and 6: @p{brk} 1) When you
  encrypt your wallet for the first time, a new keypool is created before
  Bitcoin-Qt/bitcoind shuts down. This prevents losing bitcoins if you
  backed up your newly-encrypted wallet, received coins to new addresses,
  and then later restored from the backup. @p{»»}

  @p{««}There is still a potential problem when you upgrade a
  previously-encrypted wallet: in that case, the wallet file is rewritten
  on startup and will be left with an empty keypool (new keys cannot be
  written because in this case the code doesn't have your wallet
  passphrase). The release notes suggest backing up the re-encrypted
  wallet after generating a new address. @p{»»}

  @p{««}2) Be less aggressive about deleting the database/log.* file(s) on
  shutdown @p{--} with rc6, they are only deleted if the wallet is
  successfully encrypted/re-encrypted (to make sure unencrypted private
  keys are not left in them). @p{»»}

  @p{««}Please report only show-stopper bugs in this thread@p{--} normal
  bug reports or feature suggestions should go into the github issue
  tracker: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please DO add to this thread if you've done some testing, giving
  what you tested (0.4.1? 0.5.0 ? win32 exe ? zip ? linux ?), what
  operating system you tested on, and if you were testing a fresh install
  or upgrading (and if upgrading, was your wallet encrypted before?).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1272}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 19:01:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52190.msg623190@s{hash}msg623190
@section 3 {tx}

  @p{««}The hosts of Free Talk Live know quite a lot about Bitcoin@p{--} I
  had lunch with them last year (there's a thread in here somewhere about
  that....). @p{»»}

  @p{««}RE: "don't emphasize the potential illegal uses" @p{--} mmmm. Last
  I heard, Ian was enthusiastic about the Silk Road, so I'd expect it to
  be part of the conversation. @p{»»}

  @p{««}And I think one of the people associated with the show (I'm being
  vague because I don't want to reveal something they don't want revealed)
  lost some bitcoins when MyBitcoin went away, so I'd expect
  security/trust issues to be raised, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1273}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 19:05:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52195.msg623194@s{hash}msg623194
@section 3 {tx}

  @p{««}If I recall correctly, the courts have ruled that "commercial
  speech" is not as protected@p{--} so laws that restrict (for example)
  cigarette ads on television are OK. @p{»»}

  @p{««}Bitcoin transactions would, I think, be very likely to be
  classified by the courts as non-protected speech, if they were
  classified as 'speech' at all. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1274}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-18 22:29:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52183.msg623421@s{hash}msg623421
@section 3 {tx}

  @s{quotedtext}

  @p{««} First: sounds like a bug in Mt Gox's bitcoin address validation
  code that they should fix. @p{»»}

  @p{««}Second: Do you own the testnet wallet with that address in it? If
  @p{(ul}you@p{??)} do, then it is possible to transfer the public/private
  keypair from your testnet wallet to your main wallet and recover the
  coins (but you'll need to use PyWallet or one of sipa's export/import
  private keys bitcoin branches). @p{»»}

  @p{««}Because the coins are recoverable, you shouldn't expect Mt. Gox to
  refund the transaction... (otherwise everybody could create testnet
  versions of their main-net bitcoin addresses, withdraw, and then as Mt
  Gox to "refund" their "mistake") @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1275}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-19 16:16:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg624126@s{hash}msg624126
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't have a Linux64-with-GUI machine available to try to debug
  this, and I've failed to reproduce it on an Ubuntu 10.10 'maverick'
  server. @p{»»}

  @p{««}If you can, please test (and, if you can, help debug) on 64-bit
  Linux. This is the last issue holding up the release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1276}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-19 16:52:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52286.msg624159@s{hash}msg624159
@section 3 {tx}

  @s{quotedtext}

  @p{««}Why limit it to bitcoin businesses? @p{»»}

  @p{««}Somebody should create a website where you can get a few bitcoins
  for free, to subsidize adoption. @p{»»}

  @p{««}@p{hrule} You mean give a significant amount of bitcoins to the
  'important' businesses? @p{»»}

  @p{««}Who decides which are 'important' ? @p{»»}

  @p{««}How do you make sure somebody isn't creating fake businesses just
  to get free bitcoins ? @p{»»}

  @p{««}If you want to subsidize bitcoin businesses and have answers to
  those questions, then I heartily encourage you to go for it! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1277}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-20 00:36:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg624571@s{hash}msg624571
@section 3 {tx}

  @s{quotedtext}

  @p{««} Absolutely no guarantee is made that old, pre-rc6 private keys
  will not end up unencrypted somewhere on the disk. @p{»»}

  @p{««}There is no guarantee that newly generated, post-rc6 private keys
  will not end up on the disk, either, although the code tries to keep
  that from happening (locking memory so it is not swapped to disk, for
  example). @p{»»}

  @p{««}There should be no files containing unencrypted private keys after
  rc6 rewrites the wallet, though. @p{»»}

  @p{««}Thanks for helping test! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1278}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-20 17:18:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52378.msg625189@s{hash}msg625189
@section 3 {tx}

  @p{««}They're not throwing away 0.01 BTC, they just haven't redeemed them
  yet@p{--} they're using valid-but-strange transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1279}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-20 18:04:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg625217@s{hash}msg625217
@section 3 {tx}

  @p{««}Release Candidate 7 binaries are available at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Difference between rc6 and rc7 : rc7 does not remove BDB (Berkeley
  database) log/* files, because that is causing un-readable wallets on
  some people's machines (all the reports were from people running 64-bit
  version of Linux, but that might have just been coincidence@p{--} I
  could never reproduce the problem in any of my test environments). @p{»»}

  @p{««}What that means: old private keys can remain in a file on your disk
  even after wallet encryption, but they will eventually be removed.
  Details: @p{»»}

  @p{««}BDB closes the old logfile and opens a new one when it get close to
  10megabytes big. @p{»»}

  @p{««}When bitcoin shuts down cleanly, it asks BDB to remove any unused
  log files, and BDB will remove all but one file from database/log.*
  @p{»»}

  @p{««}So: if you encrypt your wallet, unencrypted private keys will be in
  the old part of the log file. But after running for a half a day or so,
  BDB will close that old log file and open a new one. Then, the next time
  you restart bitcoin, the old log file containing the unencrypted keys is
  removed. @p{»»}

  @p{««}This seems like a reasonable compromise between security and safety
  for now; a better wallet encryption solution for the next version of
  bitcoin (for example, one that doesn't require shutting down and
  restarting after encrypting the wallet) is a good idea, but out of scope
  for this release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1280}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-21 14:43:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52008.msg626122@s{hash}msg626122
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

  @p{««}But not being able to download the block-chain sounds like a
  networking issue that 0.5 is unlikely to fix. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1281}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-21 17:17:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52480.msg626275@s{hash}msg626275
@section 3 {tx}

  @p{««}Bitcoin version 0.5.0 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The major change for this release is a completely new graphical
  interface that uses the Qt user interface toolkit. @p{»»}

  @p{««}This release include German, Spanish, Spanish-Castilian, Norwegian
  and Dutch translations. More translations are welcome; join the project
  at Transifex if you can help: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}For Ubuntu users, there is a new ppa maintained by @p{(link}Matt
  Corallo@p{link)} which you can add to your system so that it will
  automatically keep bitcoin up-to-date. Just type "sudo
  apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install
  the bitcoin-qt package. @p{»»}

  @p{««}@p{(ul}@p{(bf}MAJOR BUG FIX (CVE-2011-4447)@p{bf)}@p{??)} @p{»»}

  @p{««}The wallet encryption feature introduced in Bitcoin version 0.4.0
  did not sufficiently secure the private keys. An attacker who @p{brk}
  managed to get a copy of your encrypted wallet.dat file might be able to
  recover some or all of the unencrypted keys and steal the @p{brk}
  associated coins. @p{»»}

  @p{««}If you have a previously encrypted wallet.dat, the first time you
  run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
  @p{brk} shut down, and you will be prompted to restart it to run with
  the new, properly encrypted file. @p{»»}

  @p{««}If you had a previously encrypted wallet.dat that might have been
  copied or stolen (for example, you backed it up to a public @p{brk}
  location) you should send all of your bitcoins to yourself using a new
  bitcoin address and stop using any previously generated addresses. @p{»»}

  @p{««}Wallets encrypted with this version of Bitcoin are written
  properly. @p{»»}

  @p{««}Technical note: the encrypted wallet's 'keypool' will be
  regenerated the first time you request a new bitcoin address; to be
  certain that the @p{brk} new private keys are properly backed up you
  should: @p{»»}

    @p{(li} 1. Run Bitcoin and let it rewrite the wallet.dat file @p{li)}

    @p{(li} 2. Run it again, then ask it for a new bitcoin address.
   @p{brk} Bitcoin-Qt: Address Book, then New Address... @p{brk} bitcoind:
   run the 'walletpassphrase' RPC command to unlock the wallet, then run
   the 'getnewaddress' RPC command. @p{li)}

    @p{(li} 3. If your encrypted wallet.dat may have been copied or
    stolen, send all of your bitcoins to the new bitcoin address. @p{li)}

    @p{(li} 4. Shut down Bitcoin, then backup the wallet.dat file. @p{brk}
   IMPORTANT: be sure to request a new bitcoin address before backing up,
   so that the 'keypool' is regenerated and backed up. @p{li)}

  @p{««}"Security in depth" is always a good idea, so choosing a secure
  location for the backup and/or encrypting the backup before uploading it
  is recommended. And as in previous releases, if your machine is infected
  by malware there are several ways an attacker might steal your bitcoins.
  @p{»»}

  @p{««}Thanks to Alan Reiner (@p{(link}etotheipi@p{link)}) for finding and
  reporting this bug. @p{»»}

  @p{««}@p{(ul}@p{(bf}MAJOR GUI CHANGES@p{bf)}@p{??)} @p{»»}

  @p{««}"Splash" graphics at startup that show address/wallet/blockchain
  loading progress. @p{»»}

  @p{««}"Synchronizing with network" progress bar to show block-chain
  download progress. @p{»»}

  @p{««}Icons at the bottom of the window that show how well connected you
  are to the network, with tooltips to display details. @p{»»}

  @p{««}Drag and drop support for bitcoin: URIs on web pages. @p{»»}

  @p{««}Export transactions as a .csv file. @p{»»}

  @p{««}Many other GUI improvements, large and small. @p{»»}

  @p{««}@p{(ul}@p{(bf}RPC CHANGES@p{bf)}@p{??)} @p{»»}

  @p{««}getmemorypool : new RPC command, provides everything needed to
  construct a block with a custom generation transaction and submit a
  solution @p{»»}

  @p{««}listsinceblock : new RPC command, list transactions since given
  block @p{»»}

  @p{««}signmessage/verifymessage : new RPC commands to sign a message with
  one of your private keys or verify that a message signed by the private
  key associated with a bitcoin address. @p{»»}

  @p{««}@p{(ul}@p{(bf}GENERAL CHANGES@p{bf)}@p{??)} @p{»»}

  @p{««}Faster initial block download. @p{»»}

  @p{««} @p{hrule} @p{brk} Thanks to everybody who contributed code or
  helped test this release: @p{»»}

  @p{««}Alan Reiner @p{brk} Alex B @p{brk} Alex Waters @p{brk} Ang Iong
  Chun @p{brk} Celil @p{brk} Chris Howie @p{brk} Chris Moore @p{brk} David
  Joel Schwartz @p{brk} David Perry @p{brk} Forrest Voight @p{brk} Gavin
  Andresen @p{brk} Janne Pulkkinen @p{brk} Jeff Garzik @p{brk} JoelKatz
  @p{brk} Khalahan @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk}
  Misbakh-Soloviev Vadim A @p{brk} Nils Schneider @p{brk} Pieter Wuille
  @p{brk} Victor Leschuk @p{brk} Wladimir J. van der Laan @p{brk} celil-kj
  @p{brk} cjdelisle @p{brk} flower @p{brk} globalcitizen @p{brk} gmaxwell
  @p{brk} kwaaak @p{brk} mark @p{brk} p2k @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1282}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-21 20:12:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52498.msg626453@s{hash}msg626453
@section 3 {tx}

  @p{««}@s{(link)} has 11,000 testnet coins available. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1283}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-21 20:43:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52498.msg626486@s{hash}msg626486
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, it aught to work (for bitcoind, at least@p{--} I haven't
  tested with bitcoin-qt). getinfo will tell you if it is working (look at
  "hashespersec"). @p{»»}

  @p{««}You might want to run a testnet-in-a-box, it is 60 time easier to
  generate blocks on it: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1284}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-21 22:29:22 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52480.msg626612@s{hash}msg626612
@section 3 {tx}

  @s{quotedtext}

  @p{««} The download directory contains them in a file called SHASUMS.asc:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... which I'll reproduce here just because it is easy: @p{»»}

   @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1285}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-22 17:14:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52517.msg627537@s{hash}msg627537
@section 3 {tx}

  @s{quotedtext}

  @p{««} Mmm... perfect software... @p{»»}

  @p{««}You notice how we aren't at Bitcoin version 1.0 yet? That the
  version is "0.5 BETA" ? @p{»»}

  @p{««}If you NEED it to be perfect then you're going to be waiting
  forever, because no software is ever perfect. @p{»»}

  @p{««}The criteria for a new 0.something release is "Is there general
  agreement that it is better than the last release." @p{»»}

  @p{««}There is general agreement that the new GUI is better; the huge
  problem with the old GUI is we have no wxWidgets GUI programmers willing
  to support the old GUI. There are several people contributing patches to
  the new Qt GUI. @p{»»}

  @p{««}I've said it before but I'll say it again: Bitcoin is still a
  high-risk, high-potential-reward experiment, and you shouldn't invest
  time or money that you can't afford to lose. We're working hard to make
  it better, but we're not perfect. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1286}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-22 17:45:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52503.msg627566@s{hash}msg627566
@section 3 {tx}

  @p{««}Yes, I forgot to rename the folder. @p{»»}

  @p{««}Uploading a fixed 0.5.0 linux.tar.gz and win32.zip now (and
  SHASUMS.asc), will do the same for 0.4.1. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1287}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-22 21:10:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48215.msg627735@s{hash}msg627735
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

  @p{««}I'm testing patches against the last two versions of Bitcoin
  (0.3.23 and 0.4.1) for BIPs 11 and 12 right now to make it as easy as
  possible for miners to support them. Review or help testing is very
  welcome: @p{»»}

  @p{««} @s{(link)} @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1288}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-22 21:17:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52480.msg627745@s{hash}msg627745
@section 3 {tx}

  @s{quotedtext}

  @p{««} I updated the .zip and .tar.gz and SHASUMS.asc a few hours ago,
  because the .zip and the .tar.gz were expanding to a "bitcoin-rc7"
  directory. @p{»»}

  @s{quotedtext}

  @p{««} Be sure you run bitcoin-qt.exe, not the old bitcoin.exe. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1289}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-23 01:25:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg627957@s{hash}msg627957
@section 3 {tx}

  @p{««}In the spirit of "do the simplest possible thing that works..." I
  think I see a very simple thing that will work. @p{»»}

  @p{««}The simple additional rule for the testnet: @p{»»}

  @p{««}If current_block_timestamp - previous_block_timestamp @s{gt} 20
  minutes: @p{»»}

    @p{(li}block difficulty = minimum difficulty @p{li)}

  @p{««}And that's it. @p{»»}

  @p{««}If mining is proceeding normally and most blocks are produced in
  less than 20 minutes, then the rules are exactly the same as the main
  network. @p{»»}

  @p{««}But if somebody has driven difficulty way up, then the new rule
  acts as a safety valve, ensuring that new blocks are created at least
  once every 20-something minutes or so. After a month of "safety valve
  blocks" the difficulty would be calculated as normal, and would get cut
  in (approximately) half. @p{»»}

  @p{««}This does make the testnet block chain more susceptible to forks
  @p{--} somebody with a bunch of hashing power can pretty easily
  invalidate a long chain of 20-minute, min-difficulty blocks if they want
  to. And there is likely to be a flurry min-difficulty blocks
  produced/announced every 20 minutes. But that could be considered a
  feature (test your block-chain-reorganization code!). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1290}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-23 19:18:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg628726@s{hash}msg628726
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why? What problem would that solve? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1291}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-23 21:01:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg628845@s{hash}msg628845
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}Any opinions on whether to do a hard reset (new genesis block with
  the new rules) or a split ("new rules apply to blocks with timestamps
  after XYZ") ? @p{»»}

  @p{««} RE: scaling down difficulty: good idea if we were thinking of
  implementing something like this for the main network. But I'd want to
  give everybody lots of time to think long and hard about potential
  hacks/exploits/unintended consequences if this was being considered for
  the main network@p{--} sudden drops in hashing power is NOT a problem
  for the main network, so I don't think it is worth considering now.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1292}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-23 22:16:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52714.msg628930@s{hash}msg628930
@section 3 {tx}

  @p{««}Good, accurate article. @p{»»}

  @p{««}I'm still not Satoshi, though. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1293}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-24 02:28:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg629178@s{hash}msg629178
@section 3 {tx}

  @p{««}Yes, who cares if you get extra testnet coins? @p{»»}

  @p{««}But... if somebody wanted to be annoying, they'd pre-generate as
  long a min-difficulty coinbase-only-transaction chain as the block
  timestamp rules allowed, and constantly broadcast those blocks. Just to
  prevent transactions from getting confirmed. @p{»»}

  @p{««}To prevent that... @p{»»}

  @p{««}Testnet could prefer to build on blocks with more transactions from
  the memory pool over blocks with fewer transactions from the memory pool
  (that's not a bad rule for main net, either; might be worth considering
  if it works well for testnet). The rule now is "build on first valid
  block seen". @p{»»}

  @p{««}And "discourage" (refuse to directly build on or relay) blocks with
  timestamps in the future. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1294}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-24 03:24:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52710.msg629215@s{hash}msg629215
@section 3 {tx}

  @p{««}Try running with the -nolisten -noirc flags, see if that works
  around the problem (and please let me know if it does/doesn't). @p{»»}

  @p{««}I'm not sure any of the current core developers regularly use TOR;
  getting somebody who does to contribute patches and review code for
  regressions is a good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1295}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-27 15:49:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52949.msg632035@s{hash}msg632035
@section 3 {tx}

  @s{quotedtext}

  @p{««} I can't see how OP_CODESEPARATOR can be used, either. I'm tempted
  to suggest that any transactions using it be 'discouraged' (have miners
  refuse to build on blocks that contain transactions using it). @p{»»}

  @p{««}Transaction hashes might be another, separate discussion
  topic@p{--} I've been thinking that the way transaction hashes are
  calculated/used could be improved, although I don't think it is a
  critical design flaw but in the category of "stuff we can live with but
  that maybe could have been done better". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1296}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-27 18:38:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52859.msg632146@s{hash}msg632146
@section 3 {tx}

  @s{quotedtext}

  @p{««} As Mike said, help on "initial headers-only download" would be
  much appreciated. @p{»»}

  @p{««}Work-in-progress is here: @s{(link)} @p{»»}

  @p{««}... and my notes on issues that have to be worked out are here:
  @s{(link)} @p{»»}

  @p{««}As for scalability in general: it looks to me like CPU time to
  validate transactions will be the bottleneck before bandwidth or disk
  space, so I don't see a strong reason to switching to a 'ledger' or
  'balance sheet' method. Effective optimization/scalability is all about
  identifying and eliminating bottlenecks. @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1297}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-27 19:02:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53028.msg632160@s{hash}msg632160
@section 3 {tx}

  @s{quotedtext}

  @p{««} I give you a transaction that sends you 11 bitcoins... but I tell
  you "you better put that in the blockchain in the next 120 blocks, or
  I'll broadcast another transaction that sends the inputs somewhere else
  so the transaction to you will be seen as a double-spend." @p{»»}

  @p{««}I'd need a bitcoin client that let me do that, and you'd need one
  that could take a transaction in some format and then let you decide
  whether or not to broadcast it for inclusion in the block chain, or told
  you "sorry, too late, inputs already spent", but that all should work
  today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1298}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-27 20:23:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53000.msg632217@s{hash}msg632217
@section 3 {tx}

  @p{««}How did you build Berkeley DB? Something like this in the MSYS
  shell: @p{»»}

    @p{(li}sh ./dist/configure -enable-cxx -enable-mingw @p{li)}

  @p{««}... should do the trick (see @p{(link}this thread@p{link)}, for
  example). @p{»»}

  @p{««}I'm no longer develop on Windows, but I had to be very careful to
  make sure bdb/boost/miniupnpc/openssl/Qt were all compiled with the same
  compiler and compatible options (e.g. -arch i386 versus -arch x86_64) to
  successfully compile bitcoind and Bitcoin-Qt on my Mac.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1299}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-28 01:16:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52859.msg632468@s{hash}msg632468
@section 3 {tx}

  @s{quotedtext}

  @p{««}Ummm, yes. @p{»»}

  @p{««}It seems to me miners will have an incentive to lie about the
  transaction ledger, and put fake ledger hashes in their blocks. Either
  so their transactions might be considered 'unspent' by unsuspecting
  nodes that trust them, or so that other miners that don't have the full
  block chain create invalid blocks (eliminate the competition!) @p{»»}

  @p{««}And I don't see a proposal that everybody check the ledger and
  reject blocks that contain invalid ledger hashes. @p{»»}

  @p{««}I also don't see what the ledger hash accomplishes. If you're going
  to trust some other node's version of unspent-transaction-reality, then
  you could just ask "send me the ledger state before (or after) the block
  with THIS block hash". @p{»»}

  @p{««}But if you're going to trust one or more nodes anyway... then it
  seems to me sending an ever-increasing-in-size ledger is a bad way to
  get scalable. If size-of-full-blockchain becomes a problem before the
  mining pools and big exchanges/merchants/transactions processors all
  have transaction processing clusters with a terabyte of ram and petabyte
  hard drive array then I think extending the protocol to make it easy to
  request all transactions involved in a given Merkle branch will probably
  be the way to go. @p{»»}

  @p{««}But before then I expect the bitcoin network will look very
  different from the way it looks today, and I expect there will be
  several different solutions for how to scale up. If (when!) Bitcoin gets
  that successful, there will be serious money hiring the same smart
  people who figured out how to scale up PayPal and Visa.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1300}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-28 20:10:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52993.msg633262@s{hash}msg633262
@section 3 {tx}

  @s{quotedtext}

  @p{««} 0.3.15 is pretty old, and the way you're spending from a copy of
  the wallet is, I suspect, confusing it. Pieter updated the wallet code
  to handle transactions with partially spent outputs a while back. @p{»»}

  @p{««}Try upgrading to version 0.4.1 or 0.5 and running -rescan and see
  if your missing bitcoins reappear. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1301}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-28 20:13:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52734.msg633264@s{hash}msg633264
@section 3 {tx}

  @p{««}The setup.exe is a "NSIS installer" @p{--} I think this will work
  (but I haven't tried it): @p{»»}

  @p{««}Code: bitcoin-0.5.0-win32-setup.exe /S 

# ----------------------------------------------------------------------
@section 2 {ms1302}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-28 20:58:33 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53128.msg633303@s{hash}msg633303
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is high on my list because I think most miners (and pools)
  would be happy to include many more free transactions than the current
  rules allow, and if there is another price spike or somebody rich
  decides it would be fun to make the block chain a couple of gigabytes
  bigger it is much easier to react if the fees are not hard-coded. @p{»»}

  @p{««}The rough plan is: @p{»»}

  @p{(li}  Give miners more "knobs" to set fee policy@p{--} let them
  specify (via command-line switch and maybe bitcoind RPC command) how
  much (if any) space to set aside in blocks for free transactions, how
  much to charge per-kilobyte and/or per-ECDSA-signature-validation, and
  what the priority/size/number-of-signatures thresholds are for
  considering a transaction for inclusion in the free space.  @p{li)}

  @p{(li}  As Meni says, teach clients to look at the recent blockchain
  history and, for a given transaction, estimate how much of a fee will be
  required to get it into a block reasonably quickly. Maybe a
  "createtransaction" RPC call that locks coins for a certain amount of
  time and returns the how-long-to-confirm estimate along with
  "commit/aborttransaction" calls....  @p{li)}

  @p{(li}  Figure out a reasonable UI for fees. Maybe: calculate the
  probability sending the transaction with 0 fee will get into the next,
  oh, 3 blocks, and if it is greater than, oh, 90% then just send it
  without a fee. Otherwise, let the user decide between paying a fee that
  will get it included (with 90% probability) in the next 3 blocks or
  letting them know how long it might take if they pay no fee.  @p{li)}

  @p{««}Lots of details to be worked out... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1303}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-29 16:18:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52706.msg634262@s{hash}msg634262
@section 3 {tx}

  @s{quotedtext}

  @p{««}No. @p{»»}

  @s{quotedtext}

  @p{««}See: @s{(link)} @p{brk} Opcodes 1-75 push data onto the stack.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1304}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-29 16:20:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53206.msg634265@s{hash}msg634265
@section 3 {tx}

  @p{««}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1305}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-30 02:37:36 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53221.msg634924@s{hash}msg634924
@section 3 {tx}

  @s{quotedtext}

  @p{««}You can remove the addr.dat file and run with the -noirc and
  -nodnsseed options to experiment right now. @p{»»}

  @p{««}I fixed the bootstrap-from-hard-coded seed node code a couple of
  months ago, so use a recent version of bitcoin to see it working
  properly.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1306}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-30 16:14:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53348.msg635585@s{hash}msg635585
@section 3 {tx}

  @p{««}I didn't read through the whole "what is the Libertarian solution
  to Global Warming" thread, so excuse me if I'm saying what somebody else
  has said. @p{»»}

  @p{««}And I'm not a climate scientist (although I am married to a
  geologist who is a professor in the same department as Ray Bradley and
  several other world-class climate scientists), so I can't assess the
  scientific literature and pick apart various estimates of CO2
  sensitivity or urban heat island effects on weather stations or ...
  @p{»»}

  @p{««}But it seems to me pretty clear that there is a clear consensus
  among scientists that Global Warming is happening and we're almost
  certainly the cause. @p{»»}

  @p{««}So the question for me becomes: how big a deal is it, for both
  people and our environment? @p{»»}

  @p{««}According to the climate scientists, we've @p{(link}been warming
  for 100 years now@p{link)}, and nobody seemed to notice. @p{»»}

  @p{««}I know there are worries that there will be a 'climate tipping
  point' @p{--} that warming will shut down the gulf stream or make the
  Greenland Ice Sheet fall into the ocean all at once or ocean chemistry
  changes will make all that methane down there suddenly bubble up to the
  surface. I'd be very interested in evidence that any of those things
  have ever happened in the past (because on a geological time scale the
  Earth's climate has varied a LOT). @p{»»}

  @p{««}And I'm certain warming will be bad for some species@p{--} maybe
  polar bears will go extinct. Then again, a warmer environment will be
  good for some species, and I recently read an interesting article about
  new species arising to fill empty ecological niches much more quickly
  than biologists expected (I dont' remember the details, but they were
  seeing new species arise over a period of decades instead of centuries
  or millenia). I think we all (biologists included) have a bias towards
  species that already exist, and have trouble having faith in Nature's
  ability to adapt. @p{»»}

  @p{««}So given that the world was a MUCH warmer place back when the
  dinosaurs were roaming around, and given that most people most places in
  the world didn't even notice an almost 1° C rise in temperature over the
  last century, I just don't think it will be a global catastrophe. @p{»»}

  @p{««}Which is a good thing, because I don't think the kind of global
  agreement that would be required to reduce carbon emissions has any
  realistic chance of happening@p{--} the incentives for a country or
  region to cheat (and burn lots of cheap fossil fuels) are just too
  great. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1307}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-30 16:29:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52859.msg635603@s{hash}msg635603
@section 3 {tx}

  @s{quotedtext}

  @p{««}So go implement it and see how well it works. @p{»»}

  @p{««}Create a little HTTP-based protocol with, oh, three methods: @p{»»}

    @p{(li}You send a block height or block hash, you get back a ledger
    hash.@p{li)}

    @p{(li}You send a ledger hash, you get back the full ledger or an "I
    have no idea what you're talking about, that's not a valid ledger
    hash".@p{li)}

    @p{(li}You send two ledger hashes, you get back the changes from one
    to the other or an "I have no idea what you're talking about, one of
    those isn't a valid ledger hash".@p{li)}

  @p{««}Then you just need to convince a bunch of semi-trustworthy people
  to run "ledger servers." And maybe have some mechanism for reporting
  when a ledger server has a bug or 'goes rogue' and reports a ledger hash
  that is different from everybody else. @p{»»}

  @p{««}Oh, and you might need to solve the incentive problem of "why would
  I run a ledger server if I'm not paid for it" (and maybe write a bunch
  of denial-of-service-prevention code in case some jerk with a botnet
  decides to ask for 10,000 full ledgers from 10,000 different IP
  addresses).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1308}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-30 17:38:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53348.msg635678@s{hash}msg635678
@section 3 {tx}

  @s{quotedtext}

  @p{««} How far back in history do you have to go to find a time when the
  Earth couldn't support human life? @p{»»}

  @p{««}If I recall correctly, CO2 concentrations were pretty darn high
  when the dinosaurs where walking around. There were no people around
  then, but I don't see any reason why we couldn't live in a much warmer,
  wetter world. @p{»»}

  @s{quotedtext}

  @p{««}You got it backwards. The dinosaurs came after the mass extinction
  of other species. @p{»»}

  @p{««}Which is kind of my point: if there IS a mass extinction event,
  then that sucks for the species that go extinct. But new species will
  arise that are well-adapted to the new climate. And we humans are a
  pretty darn adaptable species...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1309}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-11-30 22:06:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53348.msg636153@s{hash}msg636153
@section 3 {tx}

  @p{««}@s{image} @p{»»}

  @p{««}Maybe it is because I am married to a geologist, but I tend to look
  at a longer timescale. When the dinosaurs were around CO2 concentrations
  were up around 3000ppm. @p{»»}

  @p{««}I'm not saying there will be no effects of global warming@p{--} I
  am claiming that we, and mother nature, will adapt. @p{»»}

  @p{««}We could argue about whether it would be less expensive or better
  to change our behavior now rather than just adapt later@p{--} last I
  looked, adapting by (for example) moving inland and abandoning low-
  lying cities and countries was estimated to be cheaper than spending
  money to reduce CO2 emissions.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1310}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-01 00:46:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53348.msg636332@s{hash}msg636332
@section 3 {tx}

  @s{quotedtext}

  @p{««} Umm, they seemed to be doing OK overall when I was there a couple
  of years ago, despite the horrible drought, terrible floods, and
  Hurricane Yasi. @p{»»}

  @s{quotedtext}

  @p{««} I'm all for doing things to keep people from dying and suffering.
  Rereading the @p{(link}IPCC report@p{link)}, the big killers/dangers
  will be an increase in malaria and other diseases in poor countries.
  @p{»»}

  @p{««}It seems to me policies that make the poor countries richer (free
  trade, open immigration, stable political institutions and rule of law)
  is the best way to tackle those problems. @p{»»}

  @p{««}Or to put it another way: The US will probably spend years arguing
  over whether or not a carbon tax (or cap and trade or whatever) is a
  good idea (I'm watching to see what happens with Australia's carbon tax
  with great interest, by the way). Maybe we'll eventually pass one and
  reduce our carbon emissions. @p{»»}

  @p{««}I predict that will just move carbon-intensive industries somewhere
  else in the world, and carbon emissions will continue to rise. @p{»»}

  @p{««}I think it would be better to spend the time arguing over what we
  could do to help make poor countries rich. Or argue for open borders so
  poor people in places that are getting flooded (don't buy real estate in
  Bangladesh...) have a place to go. @p{»»}

  @p{««}Or, if you REALLY think rising CO2 levels will be a catastrophe,
  then rich countries or individuals should create solar-powered CO2
  scrubbers and spend money installing gazillions of them in the desert.
  Because betting on the whole world coming together and agreeing to do
  something is about a million times @p{(it}less@p{it)} likely than
  getting everybody on this forum to agree on... well, pretty much
  anything. @p{»»}

  @s{quotedtext}

  @p{««} Don't buy real estate in Florida. New York will be mostly OK ("The
  average elevation of Manhattan is reported to be 29 meters (97 feet"); I
  can't find a mean elevation for LA, but city hall is 300 feet above sea
  level so unless you buy beachfront property you'll be OK. @p{»»}

  @p{««}With global warming, we're talking changes that happen over a
  hundred or three (or more) years. I may be wrong (I often am), but I'd
  be the big worry 100 years from now will not be global warming, but
  something else. Maybe running out of Unobtanium for our flying cars....
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1311}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-01 01:17:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53402.msg636382@s{hash}msg636382
@section 3 {tx}

  @p{««}Neat idea! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1312}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-01 01:52:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=46927.msg636428@s{hash}msg636428
@section 3 {tx}

  @p{««}I don't know nuthin about merged mining@p{--} anybody have
  objections to Luke-Jr's pull? @p{»»}

  @p{««}My only concern is: will this be a "used by exactly one person (the
  Eligius pool)" feature? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1313}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-01 03:01:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=52859.msg636521@s{hash}msg636521
@section 3 {tx}

  @s{quotedtext}

  @p{««} Interesting idea! @p{»»}

  @p{««}Thinking out loud... There Doesn't Have To Be One Way To Do It.
  Piuk (or somebody) should hack together a client or miner that uses a
  ledger system; it could refuse to relay or include any transactions with
  inputs smaller than 0.001 BTC, so it only needed a truncated ledger to
  create new blocks (if it is a miner, maybe it connects to a trusted
  'traditional' bitcoin node to make sure it only builds on valid blocks
  which might contain tiny inputs). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1314}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-01 03:08:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53042.msg636534@s{hash}msg636534
@section 3 {tx}

  @s{quotedtext}

  @p{««}The Bitcoin Faucet has an excellent safety record. Only one user
  reportedly drowned, but that was because they were trying to solve the
  CAPTCHA on their iPhone when walking next to a swimming pool. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1315}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-02 00:20:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53505.msg637787@s{hash}msg637787
@section 3 {tx}

  @p{««}How: @p{»»}

  @p{««}CNode::Misbehaving(int howmuch) is called when code detects that a
  peer is doing something out-of-the-ordinary. In this case, if a peer
  sends you a block that can't possibly be in the best chain,
  Misbehaving(100) is called. @p{»»}

  @p{««}When a Node accumulates a misbehavior score greater than or equal
  to "-banscore" (default 100), their connection is dropped and their IP
  address is banned from reconnecting for "-bantime" seconds (default 24
  hours). @p{»»}

  @p{««}When are they un-banned: @p{»»}

  @p{««}After -bantime seconds. But the list of banned IP addresses is
  stored in memory, so if you shutdown and restart bitcoin everybody is
  un-banned. @p{»»}

  @p{««}There is no way to see the list of currently banned nodes, but you
  will see "Disconnected n.n.n.n for misbehavior" and "connection from
  n.n.n.n dropped (banned)" in the debug.log. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1316}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-02 00:24:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48215.msg637791@s{hash}msg637791
@section 3 {tx}

  @s{quotedtext}

  @p{««}I think the version on the bitcoin wiki ( @s{(link)} ) is a little
  more up-to-date, but you should check with genjix, he's the BIP-meister.
  @p{»»}

  @p{««}Pull request for BIPS 11 12 and 13 is here: @s{(link)} @p{brk}
  Unless I hear objections, I'll probably pull it tomorrow.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1317}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-02 00:57:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48215.msg637823@s{hash}msg637823
@section 3 {tx}

  @s{quotedtext}

  @p{««} (A-and-B)-or-C will wait for another BIP; there are some nifty
  (and generalizable) ways of doing that by using OP_EVAL recursively that
  have the added benefit of keeping never-used public keys out of the
  blockchain. @p{»»}

  @p{««}(1,1) is silly but standard according to BIP 11. It is just a
  slightly larger version of the standard @p{lt}sig@s{gt}
  @p{lt}pubkey@s{gt} OP_CHECKSIG form used by most coinbase transactions.
  @p{»»}

  @p{««}I think (1,2)....(3,3) combined with all the things that can be
  done with deterministic keys or "I only have part of the private key" or
  other tricks will enable plenty of innovative solutions. @p{»»}

  @p{««}Just thinking off the top of my head: what interesting things could
  you do if you create 3 keys, where the private key for the third is the
  product of the first and second? If you make them a 2-of-3-to-redeem, is
  that the same as an (a and b) OR c transaction? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1318}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-02 01:02:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53505.msg637828@s{hash}msg637828
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, it ignores the block. @p{»»}

  @p{««}Pulling out just the detect-too-low-difficulty-blocks parts
  wouldn't be terribly hard.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1319}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-02 02:07:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=48215.msg637890@s{hash}msg637890
@section 3 {tx}

  @p{««}BIP 12 says: "If there are any OP_EVALs in the deserialized script
  they are also executed, but recursion is limited to a depth of 2."
  @p{brk} I waffled on whether to propose any recursion at all, but I
  think just a touch of recursion will be safe and very useful. @p{»»}

  @p{««}And I wasn't clear, because I'm just thinking out loud: I meant
  take two big 256-bit random numbers (call them n1 and n2) and then
  produce three keypairs, where the private keys are n1, n2, and n1*n2.
  Thinking a little further, a 2-of-2 with that key arrangement gives a
  kind of "a and b OR c" ... but if c knows both n1 and n2 then the n1*n2
  is redundant.... @p{»»}

  @p{««}Anyway, my point was that with some cleverness I think lots of
  things become possible with just what is proposed with BIP 11, and I'd
  like to give people time to explore what can be done and figure out how
  to make this stuff easy to use before thinking about even more
  complicated transaction types. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1320}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-05 00:00:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53693.msg640614@s{hash}msg640614
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why the change: because it is twice as fast to compile just
  32-bit, a 32-bit-only executable is smaller and faster to download, and
  there is no advantage to running 64-bit (bitcoin doesn't need more than
  4 gigabytes of memory, there are no performance-critical routines that
  would be faster running 64-bit, etc). @p{»»}

  @p{««}If there's a good reason to compile 64-bit, or if we ever drop
  support for 32-bit Macs then a 64-bit version would make sense.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1321}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-05 16:25:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53215.msg641149@s{hash}msg641149
@section 3 {tx}

  @p{««}The advice here is very relevant: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1322}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-05 19:21:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg641251@s{hash}msg641251
@section 3 {tx}

  @p{««}Eligius is the first pool to support OP_EVAL@p{--} thanks Luke-Jr !
  Block @p{(link}155974@p{link)} is the first "I support OP_EVAL" block in
  the chain. @p{»»}

  @p{««}The pull request for the next version of bitcoin is ready to go:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and there are backports of just the changes relevant to mining
  available at these git branches: @p{»»}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} @p{li)}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1323}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-05 22:07:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50223.msg641378@s{hash}msg641378
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}@p{(bf}Testnet difficulty calculation changes, to take effect Jan 1
  2012@p{bf)} @p{»»}

  @p{««}Allow mining of min-difficulty blocks if 20 minutes have gone by
  without mining a regular-difficulty block. @p{brk} Normal rules apply
  every 2016 blocks, though, so there may be a very-slow-to-confirm block
  at the difficulty-adjustment blocks (once per month, assuming testnet is
  in it's normal "difficulty too high for number of people mining it"
  state). @p{»»}

  @p{««}This will almost certainly cause a testnet blockchain split after
  Jan 1. After pulling I'll update the Testnet Faucet, I'll ask theymos if
  he can update the testnet block explorer bitcoind. @p{»»}

  @p{««}I didn't implement any "shun blocks from the future" or "prefer
  blocks with more memory-pool transactions", I want to see how well the
  simplest-thing-that-might-possibly-work solution works first. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1324}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-07 22:12:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53505.msg643422@s{hash}msg643422
@section 3 {tx}

  @s{quotedtext}

  @p{««} The misbehaving client creates orphan blocks with very low
  proof-of-work; the unlucky miner creates orphan blocks with valid
  proof-of-work. @p{»»}

  @p{««}The misbehaving client gets away with their misbehavior by either
  anchoring their bogus blocks deep in the chain, when blocks had very
  easy proof-of-work. @p{»»}

  @p{««}Or giving them a bogus "previous block hash" so they're not
  anchored anywhere in the chain at all. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1325}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-08 02:52:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53505.msg643683@s{hash}msg643683
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure@p{--} it has to be possible, there is no guarantee that
  you'll see blocks announced on the network in order. An orphan block may
  just be one that you can't connect to the main chain yet because you
  haven't seen it's parent yet (maybe you're downloading blocks and
  haven't got them all yet, or maybe a miner got lucky and only needed
  eleven hashes to build on a block and you see her block before the
  parent because of network delays). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1326}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-08 03:13:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53062.msg643695@s{hash}msg643695
@section 3 {tx}

  @p{««}Neat idea! @p{»»}

  @p{««}I don't get the economics of it, though@p{--} how do I convince the
  network to run/check the calculations I want the MerkleWeb to run rather
  than somebody else's? And does anything prevent me from asking the
  MerkleWeb to do some useless busy-work that is just designed to chew up
  computing resources? Who decides what gets run on the Turing machine,
  when? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1327}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-10 18:56:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54071.msg646227@s{hash}msg646227
@section 3 {tx}

  @p{««}So netrin: @p{»»}

  @p{««}I asked before and I'll ask again, I'm genuinely curious: @p{»»}

  @p{««}Are there password-cracking algorithms that attempt passwords from
  lowest-entropy-to-highest-entropy? @p{»»}

  @p{««}Is it even theoretically possible to sort passwords by "entropy" ?
  (seems like a hard thing to easily measure; password
  "a.b..c...d....e.....f" has low entropy, but would any password-cracking
  algorithm try it before 6 random characters?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1328}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-12 18:48:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53980.msg648273@s{hash}msg648273
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1329}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 13:15:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53804.msg649105@s{hash}msg649105
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... or, even worse, invalidate competing proof-of-stakes. @p{»»}

  @p{««}I might like proof-of-stake schemes better if somebody has a good
  plan for how to get them started@p{--} you've got a genesis block, so
  the creator starts with 100% stake. @p{»»}

  @p{««}Now what, exactly, happens to create block number 2 for
  proof-of-stake systems? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1330}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 15:35:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54416.msg649229@s{hash}msg649229
@section 3 {tx}

  @p{««}Can we come up with a scheme that uses 2-of-3 that solves the
  problem? @p{»»}

  @p{««} Key 1 is the Wallet Protection Service Key. Your wallet only knows
  the public half of that key. @p{»»}

  @p{««}Create two random keys, Key 2 and Key 3, offline. Save them,
  they're needed for backup. @p{brk} Transfer the private part of Key 2
  and just the public half of Key 3 to the online wallet. @p{»»}

  @p{««}The wallet can generate the 2-of-3 required bitcoin payment address
  (it has all 3 public keys), but can only sign for Key 2. @p{»»}

  @p{««}Normally, it will ask the wallet protection service to sign for Key
  1. @p{»»}

  @p{««}If the WPS goes out of business, the private key for Key3 can be
  imported and the wallet will be able to spend without the WPS. @p{brk}
  If the online wallet gets lost AND the WPS goes out of business, then
  Key2 and Key3 can be restored from the offline backup. @p{»»}

  @p{««} @p{hrule} @p{brk} If you care about privacy and want to make it
  harder for people to track your transactions, then you could implement a
  deterministic key scheme on top of all of that@p{--} start with keys 1,
  2 and 3 and ECC multiply them by some random number to get derived keys.
  The random number would need to be stored with the backup, in the online
  wallet, and sent to the wallet protection service, but that's OK because
  you need the random number plus 2 of the 3 secret keys to spend the
  coins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1331}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 16:05:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54451.msg649253@s{hash}msg649253
@section 3 {tx}

  @p{««}Here's how to figure it out from the Satoshi client code: @p{»»}

  @p{««}The IMPLEMENT_SERIALIZE macro is used to both store transactions on
  disk and to serialize them into a byte-array that can be hashed. @p{»»}

  @p{««}For class CTransaction, that looks like: @p{»»}

  @s{code}

    @p{(li} ( @p{li)}

    @p{(li} READWRITE(this-@s{gt}nVersion); @p{li)}

    @p{(li} nVersion = this-@s{gt}nVersion; @p{li)}

    @p{(li} READWRITE(vin); @p{li)}

    @p{(li} READWRITE(vout); @p{li)}

    @p{(li} READWRITE(nLockTime); @p{li)}

    @p{(li} ) @p{li)}

  @p{««} READWRITE is a wrapper that is overloaded to Do The Right Thing
  for all the types bitcoin deals with; for complex types like CTxOut,
  IMPLEMENT_SERIALIZE is (essentially) called recursively. @p{»»}

  @p{««}Expand out all of the types and, assuming I didn't screw up (always
  an iffy assumption), it looks like a CTransaction is serialized as:
  @p{»»}

  @s{code}

  @p{««} String all those bytes together, SHA256 them twice, and you should
  get the transaction hash for the merkle chain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1332}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 16:16:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54488.msg649260@s{hash}msg649260
@section 3 {tx}

  @p{««}Please help sanity test version 0.5.1 release candidate 1. @p{»»}

  @p{««}Why a version 0.5.1 ? To fix the bugs listed below before starting
  on 0.6 release candidate testing. @p{»»}

  @p{««}After doing some testnet testing to make sure it works properly, I
  plan on using the "alert" system built in to the client to warn 0.4
  users that if they have an encrypted wallet they need to upgrade to be
  secure. @p{»»}

  @p{««} @p{hrule} Bitcoin version 0.5.1 release candidate 1 is now
  available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bugfix-only release. @p{»»}

  @p{««}This release includes 13 translations, including 5 new
  translations: @p{brk} Italian, Hungarian, Ukranian, Portuguese
  (Brazilian) and Simplified Chinese. @p{brk} More translations are
  welcome; join the project at Transifex if you can help: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Project source code is hosted at github; we are no longer @p{brk}
  distributing .tar.gz files here, you can get them @p{brk} directly from
  github: @p{brk} @s{(link)} @s{hash} .tar.gz @p{brk} @s{(link)} @s{hash} .zip @p{»»}

  @p{««}For Ubuntu users, there is a new ppa maintained by Matt Corallo
  which @p{brk} you can add to your system so that it will automatically
  keep @p{brk} bitcoin up-to-date. Just type @p{brk} sudo
  apt-add-repository ppa:bitcoin/bitcoin @p{brk} in your terminal, then
  install the bitcoin-qt package. @p{»»}

  @p{««}BUG FIXES @p{brk} @p{»»}

  @p{««}Re-enable SSL support for the JSON-RPC interface (it was
  unintentionally @p{brk} disabled for the 0.5.0 release binaries). @p{»»}

  @p{««}The code that finds peers via "dns seeds" no longer stops bitcoin
  startup @p{brk} if one of the dns seed machines is down. @p{»»}

  @p{««}Tooltips on the transaction list view were rendering incorrectly
  (as black boxes @p{brk} or with a transparent background). @p{»»}

  @p{««}Prevent a denial-of-service attack involving flooding a bitcoin
  node with @p{brk} orphan blocks. @p{»»}

  @p{««}The wallet passphrase dialog now warns you if the caps lock key was
  pressed. @p{»»}

  @p{««}Improved searching in addresses and labels in bitcoin-qt. @p{»»}

  @p{hrule}

  @p{««}Thanks to everybody who contributed code or helped test this
  release: @p{»»}

  @p{««}Alex B @p{brk} Clark Gaebel @p{brk} Dylan Noblesmith @p{brk} Gavin
  Andresen @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael
  Hendricks @p{brk} Nick Bosma @p{brk} Nils Schneider @p{brk} Wladimir J.
  van der Laan @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1333}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 19:25:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg649425@s{hash}msg649425
@section 3 {tx}

  @s{quotedtext}

  @p{««} These bytes at the end of the coinbase: 074f505f4556414c @p{brk}
  ... are the 7-character string "OP_EVAL" (07 is the length, 4f is the
  letter O, etc). @p{»»}

  @p{««}There are no OP_EVAL transactions in that block; it isn't safe to
  send OP_EVAL transactions until after a majority of miners support it.
  @p{»»}

  @p{««}I believe Eligius is the only pool supporting OP_EVAL right now;
  Tycho of DeepBit has finished integrating the backport and has said
  he'll start supporting it after more testing, before the end of this
  month. Last I heard slush was also working on supporting it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1334}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-13 21:29:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54488.msg649522@s{hash}msg649522
@section 3 {tx}

  @p{««}I'll be uploading Release Candidate 2 binaries this afternoon, with
  two bug fixes from RC1 (text was being truncated in the wallet
  passphrase dialog box, and previous versions of bitcoin-qt did not
  display "alert" messages). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1335}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-14 00:31:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54527.msg649654@s{hash}msg649654
@section 3 {tx}

  @s{quotedtext}

  @p{««}... if you're sending a transaction, then its timestamp should be
  the time it is sent. @p{brk} And coinbase transactions should be
  assigned the block timestamp. @p{»»}

  @p{««}I think. It is odd that different machines may assign the same
  transaction different timestamps...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1336}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-14 20:03:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg650414@s{hash}msg650414
@section 3 {tx}

  @s{quotedtext}

  @p{««} So what happens when two users import the same private key into
   their wallets? @p{brk} (or you accidently or on-purpose import the same
   private key into two of your wallets?) @p{»»}

  @p{««}You can say "Don't Do That", but if they CAN do that, then they
  WILL. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1337}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-14 20:35:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg650445@s{hash}msg650445
@section 3 {tx}

  @p{««}I like "sweep" @p{--} it has very clear semantics that I think
  users will understand: "Take all the funds that were sent THERE, and
  send them to me RIGHT NOW." @p{»»}

  @p{««}Automatic sweep-every-once-in-a-while functionality would be fine,
  as long as it was coded properly (sweeps should only be done if you have
  the full block-chain, not if you're busy catching up, and shouldn't be
  done immediately to avoid a flurry of accidental double-spends if you
  have several wallets setup to sweep the same key(s)). @p{»»}

  @p{««}I don't like "import" @p{--} it has muddy semantics that I think
  users will not understand. "You kind-of-sort-of own the funds that were
  sent THERE, unless somebody else happens to have a copy of THERE that
  you may or may not know about." @p{»»}

  @p{««}Import is bad because it can lead to a situation like: @p{brk}
   Start up bitcoin, see you have 1 BTC in your wallet (sent to an
   imported private key in block 111,000) @p{brk} So you send half of it
   to your friend to pay for lunch. @p{brk} ... bitcoin chugs away, and it
   turns out that 1BTC was spent already, in block 190,000. @p{brk} User
   is all "wtf??? where did my BTC go???" @p{»»}

  @p{««}If you're an uber-geek and know what you're doing, then you should
  use geeky, dangerous tools like PyWallet to do what you want to do.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1338}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-14 21:14:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg650479@s{hash}msg650479
@section 3 {tx}

  @s{quotedtext}

  @p{««} The current import patch needs work to be of practical use to web
  services@p{--} it does a scan of the entire blockchain to find
  transactions to the newly imported key (and keeps the wallet locked that
  entire time). For any sweep/import solution to be useful for more than
  once-in-a-blue-moon use, an index of pubkeys to transactions involving
  those keys should be kept. @p{»»}

  @p{««}It seems to me the "sweep now, and re-sweep every once-in-a-while"
  functionality would work nicely for web services. Can you describe a use
  case that wouldn't work?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1339}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-14 23:34:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54542.msg650590@s{hash}msg650590
@section 3 {tx}

  @p{««}I spent some time today looking again at the state of quantum
  computing: I'm still not worried. @p{»»}

  @p{««}The D-Wave system is not a general-purpose quantum computer; it is
  pretty specialized for solving certain problems (I'm reasonably certain
  cracking ECDSA encryption is not one of the problems it would be good
  at, but I am definitely NOT a quantum crypto expert). @p{»»}

  @p{««}Skimming the research, it looks like you'd need a
  specially-constructed quantum computer with @p{(link}515 qbits and over
  100million quantum gates@p{link)}, running more than 16 million quantum
  operations to crack Bitcoin's 256-bit ECDSA private keys using Shor's
  algorithm. @p{»»}

  @p{««}There's was a good reality-check article in the New York Times just
  last week: @p{»»}

    @p{(li} @s{(link)} @p{li)}

  @s{quotedtext}

  @p{««} I've said it before: I'll start to worry when quantum computers
  can factor 64-bit numbers. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1340}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-15 15:47:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54416.msg651187@s{hash}msg651187
@section 3 {tx}

  @s{quotedtext}

  @p{««} I only half-paid-attention to all the previous deterministic
  wallet discussions, but isn't it pretty simple? @p{»»}

  @p{««}Start with a random private key and a random nonce. @p{brk} ECC
  multiply the key by SHA256(nonce+n) to get the n'th derived key. @p{»»}

  @p{««}(I think you could even get away with using the private key as the
  nonce) (and, of course, I defer to the expertise of people who know way
  more about ECC crypto than I do) @p{»»}

  @s{quotedtext}

  @p{««} It seems to me these issues will be the same no matter what
  solution is implemented. @p{»»}

  @s{quotedtext}

  @p{««} I think the next step is starting to prototype and standardize a
  protocol for communicating with WPS or escrow services to request new
  public keys, get keys signed, etc. @p{»»}

  @p{««}Supporting deterministic wallet schemes at the same time makes
  sense, in my humble opinion. @p{»»}

  @p{««}I imagine an API call that is something like "I'm customer
  @p{(link}gavin@s{at}acm.org@p{link)}. Please use whatever private key you're
  storing for me and this 256-bit number to derive a new public key, and
  send it back to me." @p{»»}

  @p{««}(details to be worked out, but note that the WPS wouldn't
  necessarily have to store that new keypair if the "Please sign" request
  included the same (@p{(link}gavin@s{at}acm.org@p{link)},256-bit-number) ....)
  @p{»»}

  @s{quotedtext}

  @p{««} As long as the API is consistent, I don't think the details of the
  deterministic wallet matter. @p{»»}

  @s{quotedtext}

  @p{««} I don't see the difference: if the WPS becomes unavailable, then
  either solution requires that the "C" key be transferred from paper (or
  wherever) to the online client. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1341}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-15 16:11:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg651211@s{hash}msg651211
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... and that's exactly why I discourage people from doing things
  like that. It is too easy for two "copies" of a wallet to get
  out-of-sync. @p{»»}

  @p{««}You have to be a geek and muck around with copying the wallet.dat
  file from one place to another to get into trouble, and that is by
  design. I have no problem at all with geeky tools that let you do
  dangerous things (like PyWallet). @p{»»}

  @p{««}The JSON-RPC interface is trickier, because adding dangerous
  functionality there might encourage web services to do not-so-smart
  things like sending private keys over unencrypted/unprotected channels
  ("Email the private key as a Christmas gift" works great for a while,
  and then the bad guys start looking for privkeys in traffic they're
  sniffing and spend them before your Dad can....) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1342}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-15 16:16:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53062.msg651220@s{hash}msg651220
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ok. So who controls the private keys? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1343}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-15 22:22:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54717.msg651521@s{hash}msg651521
@section 3 {tx}

  @p{««}Bitcoin version 0.5.1 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bugfix-only release. @p{»»}

  @p{««}This release includes 13 translations, including 5 new
  translations: @p{brk} Italian, Hungarian, Ukranian, Portuguese
  (Brazilian) and Simplified Chinese. @p{brk} More translations are
  welcome; join the project at Transifex if you can help: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Project source code is hosted at github; we are no longer @p{brk}
  distributing .tar.gz files here, you can get them @p{brk} directly from
  github: @p{brk} @s{(link)} @s{hash} .tar.gz @p{brk} @s{(link)} @s{hash} .zip @p{»»}

  @p{««}For Ubuntu users, there is a new ppa maintained by Matt Corallo
  which @p{brk} you can add to your system so that it will automatically
  keep @p{brk} bitcoin up-to-date. Just type @p{brk} sudo
  apt-add-repository ppa:bitcoin/bitcoin @p{brk} in your terminal, then
  install the bitcoin-qt package. @p{»»}

  @p{««}BUG FIXES @p{brk} @p{»»}

  @p{««}Re-enable SSL support for the JSON-RPC interface (it was
  unintentionally @p{brk} disabled for the 0.5.0 release binaries). @p{»»}

  @p{««}The code that finds peers via "dns seeds" no longer stops bitcoin
  startup @p{brk} if one of the dns seed machines is down. @p{»»}

  @p{««}Tooltips on the transaction list view were rendering incorrectly
  (as black boxes @p{brk} or with a transparent background). @p{»»}

  @p{««}Prevent a denial-of-service attack involving flooding a bitcoin
  node with @p{brk} orphan blocks. @p{»»}

  @p{««}The wallet passphrase dialog now warns you if the caps lock key was
  pressed. @p{»»}

  @p{««}Improved searching in addresses and labels in bitcoin-qt. @p{»»}

  @p{hrule}

  @p{««}Thanks to everybody who contributed code or helped test this
  release: @p{»»}

  @p{««}Alex B @p{brk} Clark Gaebel @p{brk} Dylan Noblesmith @p{brk} Gavin
  Andresen @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael
  Hendricks @p{brk} Nick Bosma @p{brk} Nils Schneider @p{brk} Wladimir J.
  van der Laan @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1344}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-16 18:06:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54717.msg652315@s{hash}msg652315
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, those are both my PGP keys. I generated a new, stronger key
  yesterday (1FC7...) that I intend to use for code signing for the next
  release. I thought I'd changed the gavinandresen.asc file on bitcoin.org
  to contain both keys, but it looks like I didn't (or pgp/gpg doesn't
  allow more than one key in the .asc file; I was disappointed to learn
  that gpg doesn't support putting multiple signatures in an .asc file...)
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1345}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-16 19:22:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54808.msg652375@s{hash}msg652375
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1346}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-18 18:18:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54717.msg653898@s{hash}msg653898
@section 3 {tx}

  @s{quotedtext}

  @p{««} wallet.dat @p{»»}

  @p{««}wallet.dat.rewrite SHOULD be automatically removed as part of the
  upgrade-to-0.5 process; I don't know why it isn't in some cases@p{--}
  and, frankly, I would much rather spend time getting really, truly
  secure wallet solutions working. @p{»»}

  @p{««}RE: bitcoin version 0.4 starting up on your machine: @p{»»}

  @p{««}You should run the old bitcoin, un-check the "start on windows
  system startup", then exit. @p{brk} Then remove it using the Add/Remove
  Programs control panel doo-hickey (did that move again in Vista?). You
  should see both "bitcoin" (the old 0.4) and "bitcoin-qt" (the new 0.5).
  @p{»»}

  @p{««}... all of which is, I know, annoying and painful. Again, frankly,
  I'm more interested in spending time on the very-highest-priority issues
  rather than making every beta release upgrade completely smooth in all
  cases. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1347}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 00:38:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=34028.msg656908@s{hash}msg656908
@section 3 {tx}

  @p{««}RE: documentation about key encryption: @p{»»}

  @p{««}See the comment at the top of crypter.h: @p{»»}

  @p{««} Code: Private key encryption is done based on a CMasterKey,
  @p{brk} which holds a salt and random encryption key. @p{»»}

  @p{««}CMasterKeys are encrypted using AES-256-CBC using a key @p{brk}
  derived using derivation method nDerivationMethod @p{brk} (0 ==
  EVP_sha512()) and derivation iterations nDeriveIterations. @p{brk}
  vchOtherDerivationParameters is provided for alternative algorithms
  @p{brk} which may require more parameters (such as scrypt). @p{»»}

  @p{««}Wallet Private Keys are then encrypted using AES-256-CBC @p{brk}
  with the double-sha256 of the public key as the IV, and the @p{brk}
  master key's key as the encryption key (see keystore.(ch)). @p{»»}

  @p{««} The way I think of it: Take the passphrase and salt and
  SHA512-hash them nDerivationIterations times. That gets you an
  encryption key and initialization vector. @p{»»}

  @p{««}Use those to AES-256-decrypt the encrypted_key master key. @p{»»}

  @p{««}Now you can AES-256-decrypt the private keys, using the master key
  as the key and the (double-sha256-hash) PUBLIC part of the keypair as
  the initialization vector. @p{»»}

  @p{««}The "SHA-512-hash them a bunch of times" is actually done by the
  OpenSSL EVP_BytesToKey routine@p{--} documentation for that is here:
  @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1348}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 01:02:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55184.msg656925@s{hash}msg656925
@section 3 {tx}

  @p{««}My reaction to Ben Laurie's papers: @p{»»}

  @p{««}Incentives matter. @p{»»}

  @p{««} Yes, it is true that we cannot be absolutely, positively safe
  against a 51% attack unless we are absolutely certain 50% or more of the
  world's entire computing resources are dedicated to Bitcoin mining.
  @p{»»}

  @p{««}So what? @p{»»}

  @p{««}The natural incentive for somebody with lots of hashing power is to
  profit by playing by the rules, NOT to cheat. @p{»»}

  @p{««}And if you assume that your attacker is Rich and Powerful but
  Economically Irrational, then any alternative system that you propose
  will almost certainly be at least as vulnerable as Bitcoin. Create a
  system that requires 500 semi-trusted "mintettes" that all agree on a
  transaction log and then imagine 251 Special Agents infiltrating and
  corrupting the organizations that run those mintettes. @p{»»}

  @p{««}Increase the number to 40,000 mintettes to make it harder... and
  you've just re-invented Bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1349}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 01:31:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=25626.msg656950@s{hash}msg656950
@section 3 {tx}

  @s{quotedtext}

  @p{««} The standard answer is if the river is owned, then the owner(s) of
  the river will have the right incentives to keep it unpolluted. See, for
  example: @s{(link)} @p{»»}

  @p{««}If you care about clean rivers, then buy them (or donate money to
  an organization that buys them; the Nature Conservancy is one of my
  favorite charities). @p{»»}

  @p{««}It is the Chinese government's river, not the free market's, why
  are they tolerating all the pollution? @p{»»}

  @p{««}Global Warming and air pollution is a stickier problem because
  nobody owns the climate or the air we breathe, and nobody CAN own them.
  Personally, I think we do actually need good government for some things,
  which is why I describe myself as "mostly libertarian". @p{»»}

  @p{««}And if I were King, I think I'd implement the Cato Institute's
  suggestion and give all of our National Parks and public wilderness to
  private environmental organizations to take care of (or sell, if they
  decided they could put the money to better use for something else).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1350}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 15:52:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55303.msg657634@s{hash}msg657634
@section 3 {tx}

  @s{quotedtext}

  @p{««} If I thought that downloading and installing software onto your
  computer is the way to go then I'd be helping make it better. @p{»»}

  @p{««}I don't. I think 90-something-percent of future Bitcoin users will
  be using it on an iPad or mobile phone or on their computer in a web
  browser. @p{»»}

  @p{««}I'm sorry you think 0.5 is worse than 0.4, but you're in the
  (vocal) minority. Nobody stepped up to support the 0.4 wxWidgets-based
  GUI, and we've got several people working on the 0.5 Qt-based GUI, so
  I'm confident switching was the right decision. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1351}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 15:58:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55310.msg657639@s{hash}msg657639
@section 3 {tx}

  @p{««}Reposting from email to bitcoin-development mailing list: @p{»»}

  @p{««}I've been busy pulling patches into git HEAD for a Bitcoin version
  0.6, with the goal of having a Release Candidate 1 out in a couple of
  weeks. @p{»»}

  @p{««}So if you've done all your Christmas shopping and have time to help
  test, code review, etc. now would be the time. @p{»»}

  @p{««}Major changes pulled so far: @p{»»}

  @p{««}Implement BIP
  @p{(link}11@p{link)}/@p{(link}12@p{link)}/@p{(link}13@p{link)}: @p{»»}

    @p{(li}"Standard" multisignature transactions @p{li)}

    @p{(li}"Standard" OP_EVAL transactions @p{li)}

    @p{(li}OP_EVAL bitcoin addresses @p{li)} Implement @p{(link}BIP
  14@p{link)} (separate protocol from client version) @p{brk} Private key
  import/export (RPC commands, not GUI) @p{brk} New DNS seeds @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1352}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 19:10:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55260.msg657831@s{hash}msg657831
@section 3 {tx}

  @p{««}No, I bet nobody knows if or how TD F 90-22.1 applies to Bitcoin.
  @p{»»}

  @p{««}I am not a lawyer, but I bet the IRS would say that you should
  report any funds greater than $10,000 held by non-US bitcoin exchanges
  or wallet services. @p{»»}

  @p{««}I don't know what the IRS would say about Bitcoins held on a server
  that you control but that happens to be located outside the US, or if it
  would matter if they were also held on your computer or printed out and
  stored in a safe deposit box somewhere in Kentucky. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1353}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 20:26:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54654.msg657925@s{hash}msg657925
@section 3 {tx}

  @p{««}The coinbase must be between 2 and 100 bytes long and must be valid
  when deserialized as a @p{(link}"CScript"@p{link)}, but may contain
  arbitrary data. @p{»»}

  @p{««}Block 158479 looks like it is doing merged mining. @p{brk} The
  '07456c6967697573' at the start is the string 'Eligius'. @p{brk} The
  stuff in the middle looks like hashes for other block chains. @p{brk}
  And the '074f505f4556414c' at the endis is the string 'OP_EVAL'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1354}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-21 21:08:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54671.msg657984@s{hash}msg657984
@section 3 {tx}

  @s{quotedtext}

  @p{««}Use: @p{brk} @p{(link}contrib/wallettools/walletunlock.py@p{link)}
   @p{brk} and @p{brk}
   @p{(link}contrib/wallettools/walletchangepass.py@p{link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1355}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-22 13:40:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55310.msg658754@s{hash}msg658754
@section 3 {tx}

  @p{««}BIP 11/12/13 support is Core functionality only for 0.6@p{--} the
  network needs to support the new transaction types BEFORE users start
  using them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1356}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-23 03:54:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50707.msg659791@s{hash}msg659791
@section 3 {tx}

  @p{««}OP_EVAL, and OP_EVAL-bitcoin-address support were pulled into the
  master git branch two days ago; the plan is still to evaluate miner
  support on January 15, and if a majority of miners are supporting it
  (looks like that won't be a problem), to roll out version 0.6 with the
  low-level support fully enabled. @p{»»}

  @p{««}And Luke-Jr is correct: sending coins into an OP_EVAL transaction
  is perfectly safe, but until February 1 it will be unsafe to spend them.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1357}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-23 15:04:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54977.msg660214@s{hash}msg660214
@section 3 {tx}

  @s{quotedtext}

  @p{««} Run them inside a virtual machine that you don't use anything else
  for and you're almost certainly safe. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1358}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-23 15:16:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55506.msg660224@s{hash}msg660224
@section 3 {tx}

  @p{««}So... @p{»»}

  @p{««}I've been mostly quiet about the alternative block chains, but I
  have to say I'm a little disappointed. @p{»»}

  @p{««}I had hoped that they would be full of interesting experiments with
  different transaction types or smart contracts or different fee-setting
  algorithms or maybe some innovative scheme for instant transactions.
  @p{»»}

  @p{««}Instead, it seems like you've been too busy dealing with low
  hashrates and transaction-spam attacks, and have been spending all of
  your time re-inventing a lot of infrastructure (exchanges and block
  explorers and mining pool software and etc.). @p{»»}

  @p{««}I'm curious to hear what other people think: will altchain
  innovation pick up in 2012? Am I irrationally biased and just not seeing
  the awesome power of (insert-your-favorite-altchain-feature-here)? @p{»»}

  @p{««}I think there's an interesting dynamic, where the larger and more
  popular an altchain gets, the harder it is to do things like schedule a
  block-chain splitting-change (because you have to get all your exchanges
  and mining pools and etc. to upgrade). I wonder if that means the
  experimentation will only happen with brand-new blockchains, and if a
  blockchain will only really take off it the inventor manages to "get it
  99% right" the very first time... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1359}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-24 03:07:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55310.msg660802@s{hash}msg660802
@section 3 {tx}

  @s{quotedtext}

  @p{««} bitcoin/bitcoin is the 0.6 tree @p{»»}

  @p{««}I haven't done a code review of the anon-ish coin control, so I
  don't know if it will mess up 0.6 testing; it might interfere with the
  multisignature transaction changes. @p{»»}

  @p{««}The github issues tracker is the best to report any bugs you find,
  for general "it sucks" or "I love it" or "can you make this new RPC
  command to this" the best place is either IRC chat or right here. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1360}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-24 03:09:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55536.msg660804@s{hash}msg660804
@section 3 {tx}

  @p{««}@s{(link)} : @p{»»}

  @p{««}This is designed to work nicely with 'gettransaction' and new
  'blockhash' information returned in listtransactions; it is modified
  from the 'getblock' that was in my monitorreceived patch. @p{»»}

  @p{««}@p{(bf}getblockhash @p{lt}index@s{gt} @p{brk} Returns hash of block
  in best-block-chain at @p{lt}index@s{gt}. @p{brk} @p{bf)} @p{brk} e.g.
  getblockhash 0 returns
  000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f @p{brk}
  (genesis block hash) @p{»»}

  @p{««}@p{(bf}getblock @p{lt}hash@s{gt} @p{brk} Returns details of a block
  with given block-hash. @p{brk} @p{bf)} @p{brk} e.g. ./bitcoind getblock
  $(./bitcoind getblockhash 0) returns the genesis block: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1361}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-24 03:16:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55394.msg660811@s{hash}msg660811
@section 3 {tx}

  @p{««}I was working on user-defined checkpoints today@p{--}
  command-line/bitcoin.conf (and maybe a RPC call) that just says "Add
  this block hash at this height as a checkpoint." @p{»»}

  @p{««}You and your 10 trusted friends could then run a little program
  that coordinated automatic lock-ins whenever you like... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1362}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-24 16:56:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55394.msg661179@s{hash}msg661179
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}The times the blocks are announced also matters; if my node
  suddenly sees a longer 10-block chain it has never seen before, then
  either it is a 51% attack or the network was split and just came back
  together. @p{»»}

  @p{««}If the network was split 10 blocks ago then I should see that those
  10 blocks took twice as long to create as expected. @p{»»}

  @p{««}Rating blocks is a neat idea; I can think of several potential
  criteria, there are probably more we could come up with: @p{»»}

  @p{««} @p{(li}Did I first see the block announcement long after the
  block's timestamp?@p{li)}

    @p{(li}Does it look like it is part of a network split? (two chains
    that are both producing blocks more slowly than usual)@p{li)}

    @p{(li}Are they part of a sub-chain with a 'normal' distribution of
    blocks from the well-known mining pools? (an attacker's chain won't
    have blocks from ANY of the mining pools)@p{li)}

    @p{(li}Does it contain any double-spends that conflict with alternate
    chains I know about?@p{li)}

    @p{(li}Do the transactions in it look 'normal'? (reasonable number of
    transactions, reasonable amounts)@p{li)}

  @p{««}Somebody should simulate some 51% attacks and network splits and
  try out various detection algorithms. @p{»»}

  @p{««}And maybe see if it would be practical to have a checkpoint lock-in
  rule of something like "auto-checkpoint any AAA-rated block once it is
  4-deep in the best chain". I don't think that should be built-in to
  bitcoind, but a little side program that monitored the block chain and
  the pools and told bitcoind to add a checkpoint once an hour or so would
  be pretty spiffy... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1363}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-25 16:04:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55644.msg661837@s{hash}msg661837
@section 3 {tx}

  @p{««}makomk reported a remote vulnerability that I pulled into the
  master bitcoin/bitcoin tree on December 20. If you are running git-HEAD
  code on the production network you should pull the latest code to get
  the bug fixed. @p{»»}

  @p{««}This affects only anybody who has pulled and compiled their own
  bitcoind/bitcoin-qt from the source tree in the last 5 days. @p{»»}

  @p{««}Gory details: @p{»»}

  @p{««}I made a mistake. I refactored the ConnectInputs() function into
  two pieces (FetchInputs() and ConnectInputs()), and should have
  duplicated a check in ConnectInputs for an out-of-range
  previous-transaction-output in the FetchInputs() method. The result was
  a new method I wrote to help prevent a possible OP_EVAL-related
  denial-of-service attack (AreInputsStandard()) could crash with an
  out-of-bounds memory access if given an invalid transaction. @p{»»}

  @p{««}The bug-fix puts a check in FetchInputs and an assertion in
  AreInputsStandard. This does not affect the back-ported "mining only"
  code I wrote that some miners and pools have started using. @p{»»}

  @p{««}The good news is this was found and reported before binaries with
  the vulnerability were released; the bad news is this was not found
  before the code was pulled and could have made it into the next release
  if makomk had not been testing some unrelated code. @p{»»}

  @p{««}Before releasing 0.6, I would like to have an "intelligent,
  bitcoin-specific fuzzing tool" that automatically finds this type of bug
  that we can run before every release. If anybody already has one, please
  speak up! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1364}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-27 22:32:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55310.msg664230@s{hash}msg664230
@section 3 {tx}

  @s{quotedtext}

  @p{««}I've been working hard to make sure there will be no blockchain
  split, and I've convinced myself I've thought through all the "old/new
  client sending transactions to an old/new miner" cases. @p{»»}

  @p{««}The only case where an old miner could be split off the network is
  if they are mining non-standard transactions (which means they've
  modified their mining code) and do not upgrade. If you are in that
  situation, then you should either stop adding transactions containing
  OP_NOP1 into your miner's memory pool or upgrade to interpret OP_NOP1 as
  OP_EVAL. @p{»»}

  @p{««}But I've said it before and I'll say it again: don't trust me. I
  make mistakes. Two serious bugs in my OP_EVAL/multisignature code have
  been found (and fixed) in the last week. Version 0.6 @p{(bf}will@p{bf)}
  have at least a month of release candidate testing. @p{»»}

  @p{««}I still firmly believe the benefits of the new 0.6 features far
  outweigh the risks. Please help minimize the risks; review code if you
  can, run release candidate on the testnet and try to break them, read
  the BIPS and try to think of ways bad people might use them to do bad
  things. Review the @p{(link}contingency plans@p{link)} and think about
  how they could be improved or if you could help when (when, not if)
  vulnerabilities are found. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1365}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-28 00:09:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55856.msg664337@s{hash}msg664337
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. That would be a "1 of 2 signatures required" multisignature
  transaction. @p{»»}

  @s{quotedtext}

  @p{««}That you can't do. If the coins were stolen, the thief can just
  sign them away. @p{»»}

  @p{««}I suppose you could do a "2 of 2 signatures required" and then have
  the overseer only approve transactions that were ALSO 2-of-2 required
  (where 1 was the overseer's signature). A thief could take your coins
  away, but wouldn't be able to spend them without the overseer's OK. The
  overseer wouldn't be able to take them back, though. @p{»»}

  @p{««}More complicated schemes are probably possible if you want to trust
  the overseer completely... but if you and the person you are paying
  trust the overseer completely then why bother using bitcoin transactions
  at all? Just hold accounts at the overseer and they can transfer
  balances or reverse transactions as they like.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1366}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-28 00:22:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=50547.msg664352@s{hash}msg664352
@section 3 {tx}

  @p{««}Disclaimer: I'm a Tor newbie and networking stuff isn't my strong
  suit, you probably know more about it than I do. @p{»»}

  @p{««}But: I fixed a Tor-related bug for version 0.6 a few days ago. In
  particular, I moved all of the "turn this on or turn this off if running
  over Tor" to one spot (in the init.cpp file) and reworked the code so
  that you can override all of those decisions via command-line or
  bitcoin.conf switches (e.g. specify -nolisten=0 to set nolisten to false
  so you DO listen even if running a port 9050 proxy). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1367}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-28 02:38:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55822.msg664465@s{hash}msg664465
@section 3 {tx}

  @p{««}TrundleNet (no reason) @p{brk} Transactinator (T13 for short)
  @p{brk} Eleventy (because eleven is my favorite number) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1368}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-28 02:42:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55856.msg664467@s{hash}msg664467
@section 3 {tx}

  @s{quotedtext}

  @p{««} You can do 2-of-3 (overseer holds 2, so can always spend, you hold
  1) instead to accomplish the same thing. I suppose having the overseer
  put transactions in the block-chain that everybody can see might make
  you and the people you're paying trust them more... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1369}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-28 17:50:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55856.msg665005@s{hash}msg665005
@section 3 {tx}

  @p{««}The client doesn't support multisignature transactions yet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1370}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-30 02:04:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1958.msg666795@s{hash}msg666795
@section 3 {tx}

  @p{««}The Bitcoin price ($4) was the NPR Planet Money podcast's indicator
  for their Tuesday, Dec 27 episode: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1371}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2011-12-31 22:39:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56126.msg669053@s{hash}msg669053
@section 3 {tx}

  @p{««}Wallet.dat files don't get corrupted very often; blkindex.dat or
  addr.dat corruption is much more common (which makes sense, they are
  much larger and changes all the time as new blocks are added/indexed).
  @p{»»}

  @p{««}A lot of reported "database corruption" has been Berkeley DB log
  file incompatibility (the .dat files are compatible between 4.* releases
  and across operating systems; I know the log files are NOT compatible
  from 4.7 to 4.8, I think they're cross-OS compatible too but could be
  wrong about that). @p{»»}

  @p{««}The Satoshi bitcoin code could certainly do a better job of helping
  users recover from any/all of the above, although I personally think
  that development time would be better spent on the "what if my computer
  catches fire" scenario@p{--} can we make it really easy for users to
  securely backup and restore their wallets off-site?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1372}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-01 17:53:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56095.msg669804@s{hash}msg669804
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good Idea. How are you creating the files? @p{»»}

  @p{««}What language are you writing in? Anybody want to volunteer to
  write a Satoshi-bitcoin unit tester in C++ that parses ThePiachu's
  format? Or do you already have code that runs them? Committing a
  gazillion Script unit test cases to src/test/scriptTests/ sounds like a
  very good idea to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1373}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-03 01:47:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56427.msg671699@s{hash}msg671699
@section 3 {tx}

  @p{««}@p{(link}@s{(link)}@s{hash}msg656908@p{link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1374}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-03 02:00:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56170.msg671715@s{hash}msg671715
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ok, here are three: @p{»»}

  @p{««}Authorities gather enough circumstantial evidence to get a warrant.
  They raid the guy's house/office, and find a wallet on an unencrypted
  hard disk with private keys corresponding to "B". That should be enough
  evidence to convict. @p{»»}

  @p{««}Or the guy thinks he's being clever by breaking up his 10,000 BTC
  into 50 BTC chunks and slowly, over time, transfers them to new wallets
  C, then D. Then deletes B and C. @p{brk} But he doesn't realize that the
  graph of transactions he is creating would be IMPOSSIBLE to happen by
  chance if wallets B and C belonged to innocent bystanders (what are the
  chances that, say, 10,000 stolen bitcoins were broken up into a bunch of
  pieces and then just happened to end up later in the SAME wallet?) @p{»»}

  @p{««}Or somebody with lots of connections to the bitcoin network is
  figuring out (with pretty good precision) what IP address each
  transaction is coming from. The guy doesn't use a proxy to hide his IP
  address, and the transactions from A-@s{gt}B-@s{gt}C-@s{gt}D all appear
  to come from IP addresses allow assigned by the same Internet Service
  Provider in the guy's town. The authorities subpoena the ISP and find
  out the guy was assigned those IP addresses when the transactions hit
  the network. @p{»»}

  @p{hrule}

  @p{««}All of the above is why I say it is hard to be anonymous when using
  Bitcoin, and I'd urge you not to do anything with bitcoins that would
  prompt The Authorities to bother getting subpoenas/warrants to try to
  figure out who you are. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1375}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-03 18:24:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56434.msg672468@s{hash}msg672468
@section 3 {tx}

  @s{quotedtext}

  @p{««} Don't be sad@p{--} it hasn't been wasted at all. Most of the work
  was making multisignature transactions work properly, the OP_EVAL part
  was a small amount of code (which becomes an even smaller amount of code
  under the new PayToScriptHash scheme, which is one of the reasons I like
  it). @p{»»}

  @p{««}And re: new cycle of coding/testing/etc taking 3 more months: I'm
  going to propose slipping the schedule by two weeks, which means a
  "network is fully validating the new transaction types" of Feb 15
  instead of Feb 1. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1376}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-04 01:00:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56507.msg672951@s{hash}msg672951
@section 3 {tx}

  @s{quotedtext}

  @p{««} Newer versions do this already. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1377}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-06 15:04:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56839.msg677536@s{hash}msg677536
@section 3 {tx}

  @p{««}Just thinking out loud... @p{»»}

  @p{««}... but vanity addresses using 1-of-2 multisignature transactions
  and BIP 13's new bitcoin address format could be orders of magnitude
  easier to generate. @p{»»}

  @p{««}You'd start with a normal keypair. @p{»»}

  @p{««}And simply compute the hash of the public key and another,
  arbitrary, "I don't have the private key but I don't care" public key
  (in an "OP_1 @p{lt}public_key@s{gt} @p{lt}don't care public key@s{gt}
  OP_2 OP_CHECKMULTISIG" transaction type). @p{»»}

  @p{««}You'd always spend the funds sent to the vanity address using pk1.
  @p{»»}

  @p{««}No expensive ECDSA addition or multiplication required, just lots
  of SHA256/RIPEMD160 hashing and base58 encoding and string comparing.
  @p{»»}

  @p{hrule}

  @p{««}Widespread use of the new pay-to-script address format will have to
  wait until "everybody" upgrades to support it, though. And it does make
  transactions larger (2 public keys instead of 1) than the
  find-the-right-private-key solution. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1378}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-07 14:10:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg679219@s{hash}msg679219
@section 3 {tx}

  @p{««}The consensus from @p{(link}Tuesday's IRC meeting@p{link)} is to
  replace OP_EVAL with "pay-to-script-hash" @p{--} a simpler,
  safer-but-less-powerful alternative for creating bitcoin addresses for
  multisignature and future more-complex transactions. @p{»»}

  @p{««}So please read the BIP: @s{(link)} @p{brk} And the source:
  @s{(link)} @p{»»}

  @p{««}Important dates: @p{brk} Feb 1 deadline to try to get 50+% of
  hashing power to express support. @p{brk} Feb 15: "full validation"
  pay-to-script-hash switchover date (assuming success on Feb 1) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1379}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-07 20:49:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56839.msg679669@s{hash}msg679669
@section 3 {tx}

  @p{««}I hate to inject gloom and doom into a fun topic like vanity
  bitcoin addresses... but y'all should be aware that one of my
  longer-term goals for the Bitcoin system is to make bitcoin addresses
  disappear. I hope Bitcoin software 10 years from now tells users "You're
  about to pay 11 micro-Bitcoins to Amazon.com" and not
  "2mRwtf8blahblahblah". And I'm not alone, I know Mike Hearn feels
  strongly about making bitcoin addresses go away for ordinary users.
  @p{»»}

  @p{««}If you do spent lots of time creating The World's Best system for
  mining vanity bitcoin addresses, please don't be upset or surprised if
  you find it is obsolete when "@p{(bf}@p{(it}Bitcoin 2017 Turbo++
  Enhanced Edition@p{it)}@p{bf)}" is released. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1380}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-07 23:10:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56655.msg679883@s{hash}msg679883
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because we don't have infinite programming resources, and we've
  been busy working on low-level stuff that will lead to solutions that
  will fix the "my hard drive crashed" and also the "my computer got
  infected by malware" and "my house burned down along with my computer
  and all of my USB thumbdrives" disaster scenarios. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1381}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-08 15:10:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56993.msg680835@s{hash}msg680835
@section 3 {tx}

  @s{quotedtext}

  @p{««} I love that idea! Point your camera at the product, confirm
  payment, and you're done. @p{»»}

  @p{««}RE: changing prices: I wonder if you could make little
  QR-code-capable LCD or e-ink displays cheap enough to put 20 of them in
  a vending machine. @p{»»}

  @p{««}It'd also be a great opportunity for practical jokes, like making
  the machine vend... oh, I dunno, Nerds^(TM) along with their
  popcorn.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1382}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-08 19:17:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56791.msg681157@s{hash}msg681157
@section 3 {tx}

  @p{««}My prediction for 2012: @p{»»}

  @p{««}Peer-to-peer pool technology will mature (will get easier to
  install and run), and p2pool's will be more than 25% of bitcoin hashing
  power by the end of the year. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1383}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-09 15:07:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=57288.msg682472@s{hash}msg682472
@section 3 {tx}

  @s{quotedtext}

  @p{««}What do I personally think? I think it was mean, and luke-jr
  shouldn't have done it. @p{»»}

  @p{««}But if your system has a requirement "everybody will play nice"
  then your system is broken. You have to assume that people will try to
  break what you build (and also have to assume that nobody is perfect so
  you'll have to have a way of fixing your system when you find out it is
  broken). @p{»»}

  @p{««}So my heart feels sorry for CoiledCoin; my head thinks it is
  possible Luke-Jr did all the altchains a favor by demonstrating a
  problem that needs to be solved. And I'll re-iterate what I say in my
  "Be Safe" post: only invest money or time in altcoins (or Bitcoin, for
  that matter) that you can afford to lose. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1384}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-09 15:17:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=57254.msg682488@s{hash}msg682488
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why do you assume that? @p{»»}

  @p{««}A pool operator will have hardware capable of validating X
  transactions per second. Right now, with low transaction volume, X is
  much bigger than current transaction volume, no matter what kind of
  hardware the pool operator is using. @p{»»}

  @p{««}If we assume Bitcoin is successful, eventually the number of
  transactions to be processed will be bigger than X. @p{»»}

  @p{««}The pool operator will have an incentive to sort transactions by
  the fee minus how expensive they are to process, and drop transactions
  that cost too much. (or maybe implement some more complicated strategy
  like Mike's assurance contracts@p{--} I have no idea how it will
  evolve). @p{»»}

  @s{quotedtext}

  @p{««} Miners have an incentive to lie about transaction fees to
  clients@p{--} they want higher fees, so even though they might accept
  0.001BTC for a transaction they might tell clients that the fee is
  0.005BTC. @p{»»}

  @p{««}Clients should be able to get a pretty good idea of what
  transaction fees are needed (if any) to get a transaction into the block
  chain just by watching 'tx' and 'block' messages and seeing what miners
  are actually doing, instead of trusting miners to tell the truth about
  what they are doing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1385}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-10 18:53:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=10942.msg684428@s{hash}msg684428
@section 3 {tx}

  @p{««}Are you communicating via JSON-RPC or by command-line (bitcoind
  sendmany ....) ? @p{»»}

  @p{««}There shouldn't be any limits if you're talking directly via
  JSON-RPC, but if you're calling it via the command-line then sh and bash
  and whatever Windows uses to launch processes all have length limits.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1386}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-11 00:38:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg685098@s{hash}msg685098
@section 3 {tx}

  @p{««}If we manage to get 55% or better on Feb 1, then for the next two
  week's I'll be sending out the message "Upgrade or you might be on the
  short end of a blockchain split come Feb 15" @p{--} and I expect the
  result to be a large majority of miners supporting P2SH by the Feb 15'th
  switchover date. If we're still at 55% on Feb 7'th then I'll be worried,
  too, and might advise miners to push the hard switchover date a couple
  of weeks (if they're using the patches I'm creating then it is a
  command-line argument to bitcoind). @p{»»}

  @p{««}The real danger is for the 45% @p{--} after Feb 15 (assuming the
  switchover happens) all it takes is for one old miner who is including
  non-standard transactions in their blocks to create a block containing a
  transaction that is invalid under the new rules. They announce the
  block, and any miners who haven't upgraded would happily build on it,
  only to waste some hashing power because the 55% majority will sooner or
  later reject their chain. @p{»»}

  @p{««}However, I don't think anybody will accidentally mine a block
  spending an 'invalid under the new rules transaction' in it (the number
  of people mining non-standard transactions seems to be very small), and
  it seems unlikely an attacker would waste time solving one or more
  blocks that they knew were going to be rejected by a majority of the
  network. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1387}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-11 15:24:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg685965@s{hash}msg685965
@section 3 {tx}

  @s{quotedtext}

  @p{««} Right........ @p{»»}

  @s{quotedtext}

  @p{««} Also, the worst case scenario isn't very scary@p{--} worst case is
  the less-than-50%-of-miners who did the switch find themselves on the
  short end of a blockchain split, so they lose revenue (and transactions
  take longer to confirm because the network is working on two different
  chains). @p{»»}

  @p{««}That would motivate them to either quickly recruit more hashing
  power or quickly switch back to the old rules.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1388}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-11 19:23:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg686352@s{hash}msg686352
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, not "something else", it is "if you see this very-specific
  sequence of bytes in the scriptPubKey then do this ADDITIONAL
  validation." @p{»»}

  @p{««}As for saying something in BIP 16 about obsoleting scriptPubKey :
  no. Although I think in the future we'll move towards all transactions
  being pay-to-script-hash, I think it is dumb to put anything like "we
  think this is what is going to happen in the future" into standards
  documents. @p{»»}

  @p{««}Can we keep the big picture in mind? The reason I'm pushing so hard
  for "send bitcoins to a multisignature-protected-address" functionality
  is so users stop losing their bitcoins to malware infecting their
  computers and smartphones and to scammers. @p{»»}

  @p{««}We can spend more months arguing over trivia, but I would much
  rather we spent the time thinking hard about, and building, great wallet
  and escrow solutions that solve Bitcoin's biggest technical problems.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1389}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-12 00:07:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg686834@s{hash}msg686834
@section 3 {tx}

  @s{quotedtext}

  @p{««} What percentage support by February 15'th would make you
  comfortable? As I said, if it is 55% from Feb 1 to Feb 15'th (or, worse,
  if it varies a lot in that time) then I think we'll need to re-assess. I
  expect to get well over 70% support starting Feb 1. @p{»»}

  @p{««}I'd rather use some common sense rather than spend days arguing
  about exactly what percentage aught to be specified in the BIP, or how
  many standard deviations of variance are acceptable between Feb 1 and
  15.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1390}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-12 02:32:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg687009@s{hash}msg687009
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't think they make the two-person-escrow case you describe
  any simpler; use a plain CHECKMULTISIG for that case. @p{»»}

  @p{««}I think they might make third-party escrow easier; the escrow agent
  would get public keys from all the participants and then give the buyer
  a short script hash to send the funds into escrow, instead of giving
  them three separate public keys. If all the key gathering negotiation
  happens automatically (as it should) then it doesn't really matter, but
  I suspect that it will take a while to get a secure, convenient,
  well-supported multiparty transaction negotiation protocol defined and
  implemented. So I bet pay-to-script-hashes for escrow transactions will
  get copied and pasted (or put into emailed or SMS-ed URLs) for at least
  a year or two. @p{»»}

  @p{««}But the use case I REALLY care about is the secure,
  multiple-signatures-required-to-spend wallet. Script hashes are the same
  length as existing bitcoin addresses, so it should be much easier for
  services that can already send to bitcoin addresses to be modified to
  send to multisignature script hashes (if they use bitcoind to validate
  addresses then they will just need to update bitcoind; otherwise it is a
  trivial change to their bitcoin-address-validation routine to recognize
  the new pay-to-script-hash format). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1391}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-13 15:33:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg689556@s{hash}msg689556
@section 3 {tx}

  @p{««}I just pulled p2sh into master, replacing the OP_EVAL code that I
  pulled last month before the controversy erupted. @p{»»}

  @p{««}If you think it is a bad idea, then don't use it. Hopefully it will
  inspire you to prove that I'm an idiot and completely wrong about people
  continuing to use 30-something-character "bitcoin addresses" for the
  next year or three. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1392}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-13 18:23:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg689812@s{hash}msg689812
@section 3 {tx}

  @p{««}Luke, you try my patience. @p{»»}

  @p{««}I'm going to step away from the code for a few days to calm down
  before I do something stupid because my patience is wearing thin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1393}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-13 22:49:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg690402@s{hash}msg690402
@section 3 {tx}

  @p{««}Here's my motivation for /P2SH/ or something like it: @p{»»}

  @p{««}I want to stop playing whack-a-mole with wallet stealing viruses
  and trojans, and I think requiring more than one private key to sign
  away your bitcoins is the critical feature needed to do that. Keep one
  set of keys on your computer, another set of keys on your cell phone,
  teach each to talk to the other before sending out bitcoins and you're
  safe (as long as a virus or trojan doesn't infect BOTH your cell phone
  and your computer at the same time). @p{»»}

  @p{««}The bitcoin protocol already supports that, but the bitcoin
  @p{(it}network@p{it)}, the bitcoin @p{(it}software@p{it)}, and the
  bitcoin @p{(it}addresses@p{it)} that we're all using now don't support
  multisignature transactions. @p{»»}

  @p{««}OP_EVAL and /P2SH/ and Luke's OP_CODEHASHCHECK are all slightly
  different ways of implementing multisignature transactions that are as
  short as the bitcoin addresses we're using today. @p{»»}

  @p{««} RE: the timeframe: @p{»»}

  @p{««}I'm pushing this hard because I'm tired of hearing that users lost
  their bitcoins to trojans and viruses, and getting there is a multi-step
  process that will take a lot longer than I'd like: @p{»»}

    @p{(li} 1. First a majority of miners have to validate, accept and
  mine the new transaction types. (that's the Feb 15 date) @p{brk} 2.
  Second we have to convince enough people to upgrade so that they are
  relayed around the network and not dropped @p{brk} 3. Finally, we can
  release software with wallets that use the new feature. @p{li)}

  @p{««}I'm losing patience because this process started in October, over
  three months ago, and certain people seem determined to do whatever they
  can to derail it@p{--} if I was more conspiracy-theory-minded I would
  think somebody was purposely trying to keep bitcoin less secure than it
  can be. roconnor brought up legitimate complaints with OP_EVAL that were
  discussed and addressed with /P2SH/, but I can't respond to every
  half-baked scheme that is supposedly "better" or I will spend all of my
  time explaining why something like CODEHASHCHECK is a bad idea and have
  no time left over to making Bitcoin better. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1394}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-14 14:15:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg691432@s{hash}msg691432
@section 3 {tx}

  @p{««}RE: Why OP_CODEHASHVERIFY is bad: @p{»»}

  @p{««}First, it requires that you concatenate the scriptSig and the
  scriptPubKey and execute them as on Script. @p{»»}

  @p{««}Bitcoin used to validate scripts that way, but ArtForz discovered a
  bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend
  anybody else's bitcoins. It by far Bitcoin's biggest bug and Satoshi's
  biggest brain-fart. @p{»»}

  @p{««}Part of the fix was to make executing the scriptSig completely
  independent of executing the scriptPubKey (see commit 7f7f07 in the tree
  if you're really interested). @p{»»}

  @p{««}Is there some other subtle bug involving the interaction of
  OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY
  lurking? I don't know, and I'm not about to risk all of Bitcoin to find
  out. @p{»»}

  @p{««}Second, Luke obviously isn't very familiar with all the details of
  transaction validation, or he would know that a scriptPubKey needs to
  leave a true value on the stack or validation fails. So either
  OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in
  which case it is inconsistent with the other VERIFY opcodes that
  consumer their operands) or it should be OP_CODEHASHEQUAL. @p{»»}

  @p{««}Third, the whole reason OP_EVAL caused controversy and was
  withdrawn is because adding a new opcode is more risky than adding a
  little extra validation logic. OP_CODEHASHVERIFY is almost as risky as
  OP_EVAL. @p{»»}

  @p{««}Fourth, the code Luke posted is a joke. @p{(so}He doesn't modify
  VerifyScript to combine the scriptSig and scriptPubKey, so there is no
  way for the code hash to get communicated between the scriptSig and the
  scriptPubKey.@p{so)} I think he is just trying to do whatever he can to
  cause trouble and confusion. @p{»»}

  @p{««}strikethrough added: I read through his code again and his code is
  a joke for a different reason than I thought at first glance (I missed
  the vchLastScript nonsense).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1395}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-15 15:50:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg693129@s{hash}msg693129
@section 3 {tx}

  @p{««}piuk: please read BIP 0001, it describes the process for getting
  BIP numbers assigned.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1396}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-16 17:28:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg695243@s{hash}msg695243
@section 3 {tx}

  @p{««}All righty, I mostly stepped away from the keyboard for a couple of
  days and I'm less frustrated and angry. @p{»»}

  @p{««}So first, I want to apologize to Luke for calling his CODEHASHCHECK
  code "a joke." I was frustrated that after weeks of discussion and
  gathering consensus around /P2SH/ he and piuk (and a couple others)
  decide it would be a good idea to propose
  slightly-different-but-not-obviously-better alternatives. @p{»»}

  @p{««}I still think Luke went about this the wrong way; for example, I
  think I would have been happy to accept a patch that made supporting
  /P2SH/ optional if he had presented it rationally instead of posting
  "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy
  to accept a patch turning on/off the "put /P2SH/ in the coinbase"
  (assuming the general consensus is that is a good idea), but that's a
  discussion that should happen in the Dev/Tech forum. @p{»»}

  @p{««}In fact, most of the discussion in this thread on the merits of
  various proposals belongs in the Dev/Tech forum, and most of the
  concerns expressed here in this thread @p{(bf}have@p{bf)} already been
  discussed over the last several months. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1397}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-16 21:20:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58450.msg695618@s{hash}msg695618
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, that's not a realistic attack. @p{»»}

  @p{««}For an attacker to feed you a malicious block chain, they would
  have to be able to produce malicious blocks that have CORRECT
  proof-of-work. I don't think it is realistic to think that any attacker
  would throw lots of hash power onto a malicious block chain just so they
  can feed a bad block chain to somebody who connects to them. @p{»»}

  @p{««}Especially since that somebody would discover that their version of
  the block chain was incorrect within about 10 minutes, as soon as they
  got a new block message. @p{»»}

  @p{««}The bugfix was a "belt and suspenders" change to limit the
  potential damage from somebody who already had more than 50% of hashing
  power. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1398}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 14:15:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg696668@s{hash}msg696668
@section 3 {tx}

  @s{quotedtext}

  @p{««} The code is written and committed to the master branch, backports
  are available for every bitcoin release since 0.3.19, and I'm as
  confident as I can be there are no major bugs or "gotchas" hiding in the
  pay-to-script-hash code. Several of the big mining pools have been
  testing it and will start deploying it on the main network. @p{»»}

  @p{««}"This stuff" IS programmed in a way so it is only activated on the
  main network after an agreed-upon time. @p{»»}

  @p{««}There are still two weeks until we look and see how much support it
  has, and almost a month before /P2SH/ transactions are fully validated
  on the main network. You want to wait 30,000 more blocks? More than 7
  months? That's a darn good way to get everybody to ignore the issue for
  6 months and then restart this debate from square one with 1 month to go
  and a whole fresh set of people who think they're being helpful
  suggesting using OP_ADD to combine private keys because they don't
  realize we thought about and discarded that idea 4 months ago. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1399}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 14:16:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58821.msg696670@s{hash}msg696670
@section 3 {tx}

  @p{««}Is this open source?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1400}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 22:15:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg697444@s{hash}msg697444
@section 3 {tx}

  @s{quotedtext}

  @p{««} notme is exactly right; the change is backwards-compatible, pool
  users don't have to do anything. @p{»»}

  @p{««}Pools and solo miners should upgrade, or they run a (very small)
  risk that they'll waste time hashing a block that can't be valid. @p{»»}

  @p{««}The risk is very small because it requires that somebody mine a
  block containing a /P2SH/ transaction that is valid-under-the-old-rules,
  invalid-under-the-new. That won't happen by accident, somebody malicious
  will have to create such a transaction and then find a miner who is
  willing to put that non-standard transaction in their block (and is
  willing to create a block they know the network will reject). @p{»»}

  @p{««}They would spend a lot of time (and therefore money) on an attack
  that would do nothing but slow down transaction confirmations a tiny bit
  and maybe trip up some random, unlucky mining pool or solo miner who
  didn't bother upgrading. @p{»»}

  @p{««}Gory details if you're not already bored: @p{»»}

  @p{««}Old miners and clients will ignore all /P2SH/ transactions; they
  won't relay them to other nodes and won't put them in blocks they mine,
  because they're non-standard. So an attacker can't broadcast an invalid
  /P2SH/ transaction and hope it gets included in a block; they'll have to
  mine a block themself, or partner with a big solo miner or pool who is
  willing to produce bad blocks. @p{»»}

  @p{««}If an attacker DID manage to create a block with a timestamp after
  the switchover date and a bad /P2SH/ transaction in it, then some
  percentage of the network will try to build on that bad block. Lets say
  70% of hashing power supports /P2SH/. That would mean only 70% of the
  network was working on a good block-chain, and the result would be
  transactions taking, on average, about 14 minutes to confirm instead of
  the usual 10 minutes. @p{»»}

  @p{««}In other words: they'd give up a $300 block reward and manage to
  just give the network a tiny little hiccup. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1401}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 23:00:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg697626@s{hash}msg697626
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, of course. I did most of my testing on 'testnet-in-a-box'
  nodes, but spent a day producing P2SH blocks and transactions on
  testnet; see, for example this transaction that spends a P2SH
  transaction: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Today I created a smart 'transaction fuzzer', and tomorrow I'll be
  creating and running stress-tests for the new p2sh and multisignature
  code to try to catch anything code review and unit tests might have
  missed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1402}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 23:15:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg697715@s{hash}msg697715
@section 3 {tx}

  @s{quotedtext}

  @p{««} So what happens if I put two OP_P2SH's in a scriptPubKey? What
  happens if I put one in a scriptSig? What if I put it inside an OP_IF
  ... OP_ENDIF ? @p{»»}

  @p{««}I think you're really just suggesting that the "magic" scriptPubKey
  be 24 bytes big instead of 23, and start with one of the NOP
  opcodes@p{--} yes? In which case there is going to be a special case
  code path anyway. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1403}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-17 23:19:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=59985.msg697733@s{hash}msg697733
@section 3 {tx}

  @p{««}I did some work today that should be useful to stress-test
  transaction handling for alternative bitcoin implementations: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}From its README.md: @p{»»}

  @p{««}Hacked version of Bitcoin that adds a "relayfuzzed" command. Note:
  this only works on the testnet. @p{»»}

  @p{««}@p{(bf}USING THIS CODE@p{bf)} @p{»»}

  @p{««}First, create one or more transactions using the send* RPC
  commands, and remember their transaction IDs. This version of bitcoin is
  modified so 'original' wallet transactions are not announced to the
  network. @p{»»}

  @p{««}Then, you can generate as many "fuzzed" variations as you like
  using the relayfuzzed command, which takes a transaction ID and an
  integer to seed a random number generator. @p{»»}

  @p{««}Example usage from a bash prompt: @p{»»}

   @s{code}

  @p{««} bc2 -daemon @p{»»}

  @p{««}@s{hash} Now fuzz a send-to-self: @p{brk} TXID=$(bc1 -testnet
  sendtoaddress $(bc1 getnewaddress) 0.01) @p{brk} for i in {1..100}; do
  bc1 relayfuzzed $TXID $i; done @p{»»}

  @p{««}The result should be a long list of fuzzed transaction ids, almost
  all of which are actually bad, invalid transactions. And a lot of
  "ConnectInputs failed" in testnet-box/2/testnet/debug.log @p{»»}

  @p{««}@p{(bf}THINGS TO BE AWARE OF@p{bf)} @p{»»}

  @p{««}You will trigger the denial-of-service-prevention code using this.
  If you are running a "testnet-in-a-box" setup (see @s{(link)}) then you
  don't have to worry, nodes running on localhost don't disconnect each
  other for bad behavior. Otherwise, you can run bitcoind with
  -banscore=999999 to avoid being disconnected. @p{»»}

  @p{««}Running the code being tested under Valgrind or Purify or another
  memory-corruption detection tool is a good idea. @p{»»}

  @p{««}Types of "high-level" fuzzing done: @p{»»}

  @p{««}Insert random opcodes at the front of the transactions's
  scriptSig(s) @p{»»}

  @p{««}Types of "low-level" fuzzing done: @p{»»}

  @p{««}Change bit in one of the transaction's bytes @p{brk} Delete one or
  more bytes @p{brk} Insert one or more random bytes @p{»»}

  @p{««}@p{(bf} @p{(li}TODO:@p{bf)} @p{li)}

  @p{««}Generate mostly-random scriptSig/scriptPubkey pairs that validate,
  and generate pairs/chains of valid transactions that spend them.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1404}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-18 17:05:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg699864@s{hash}msg699864
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, the next step is to get miners and clients to recognize a new
  'standard' transaction type that does multisig. @p{(link}BIP 11@p{link)}
  describes them, they're already supported in git HEAD and by the p2sh
  code, and old miners and clients will recognize and validate blocks that
  contain OP_CHECKMULTISIG transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1405}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-19 13:23:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg701805@s{hash}msg701805
@section 3 {tx}

  @s{quotedtext}

  @p{««}Just the bitcoind node.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1406}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-19 13:26:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60272.msg701809@s{hash}msg701809
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. Somebody should do that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1407}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-20 15:21:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg703783@s{hash}msg703783
@section 3 {tx}

  @p{««}Once transactions are validated and buried "deep enough" in the
  blockchain you can forget their inputs, because the inputs are only
  needed for validation. @p{»»}

  @p{««}... although SOMEBODY on the network should remember them, in case
  I-don't-trust-anybody nodes want to validate the entire blockchain.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1408}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-20 16:53:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg703923@s{hash}msg703923
@section 3 {tx}

  @p{««}I haven't seen discussion of @p{(link}BIP 17@p{link)} anywhere
  besides IRC, so I thought I'd start one. @p{»»}

  @p{««}I'll start by saying that I'm trying hard to put aside my biases
  and dispassionately evaluating the proposal on its merits (I'll just say
  that I'm not happy with the way BIP 17 came to be, but it is what it
  is). @p{»»}

  @p{««}Quick executive summary of BIP 17: @p{»»}

  @p{««}A new opcode is proposed, OP_CODEHASHVERIFY, that replaces OP_NOP2.
  @p{»»}

  @p{««}It is used in a new "standard" scriptPubKey that looks like: @p{»»}

   @s{code}

  @p{««} ... which is redeemed using a scriptSig like (for example, a
  2-of-2 CHECKMULTISIG): @p{»»}

  @p{««} Code: OP_0 @p{lt}signature@s{gt} OP_CODESEPARATOR 2
  @p{lt}pubkey1@s{gt} @p{lt}pubkey2@s{gt} 2 OP_CHECKMULTISIG @p{»»}

  @p{««}OP_CODEHASHVERIFY is defined to take the hash of everything in the
  scriptSig from the last OP_CODESEPARATOR and compare it to the top item
  on the stack. If the hashes match, then it is a no-op, otherwise script
  validation fails. (see the spec for all the details for what happens if
  there is no CODESEPARATOR or a CODEHASHVERIFY is put in the scriptSig)
  @p{»»}

  @p{««} BIP 17 is an alternative to BIP 16, which has a scriptPubKey:
  @p{»»}

   @s{code}

  @p{««} ... which is redeemed with: @p{»»}

  @p{««} Code: OP_0 @p{lt}signature@s{gt} OP_PUSHDATA(2 @p{lt}pubkey1@s{gt}
  @p{lt}pubkey2@s{gt} 2 OP_CHECKMULTISIG) @p{»»}

  @p{««}I see the appeal of BIP 17 @p{--} the redeeming opcodes aren't
  "hidden" as serialized bytes, they're right there in the scriptSig. That
  feels less like a hack. @p{»»}

  @p{««}However, there are a couple of practical reasons I like BIP 16
  better: @p{»»}

  @p{««} @p{(li}Old clients and miners count each OP_CHECKMULTISIG in a
  scriptSig or scriptPubKey as 20 "signature operations (sigops)." And
  there is a maximum of 20,000 sigops per block. That means a maximum of
  1,000 BIP-17-style multisig inputs per block. BIP 16 "hides" the
  CHECKMULTISIGs from old clients, and (for example) counts a 2-of-2
  CHECKMULTISIG as 2 sigops instead of 20. Increasing the MAX_SIGOPS limit
  would require a 'hard' blockchain split; BIP 16 gives 5-10 times more
  room for transaction growth than BIP 17 before bumping into block
  limits.@p{li)}

    @p{(li}With BIP 17, both transaction outputs @p{(bf}and@p{bf)} inputs
    fail the old IsStandard() check, so old clients and miners will refuse
    to relay or mine both transactions that send coins into a
    multisignature transaction @p{(bf}and@p{bf)} transactions that spend
    multisignature transactions. BIP 16 scriptSigs look like standard
    scriptSigs to old clients and miners. The practical effect is as long
    as less than 100% of the network is upgraded it will take longer for
    BIP 17 transactions to get confirmed compared to BIP 16
    transactions.@p{li)}

    @p{(li}Old clients and miners will immediately accept ANY scriptSig
    for BIP 17 transactions as valid. That makes me nervous; if anybody
    messes up and sends coins into a BIP 17 transaction before 50% of
    hashing power supports it anybody can claim that output. An advantage
    of BIP 16 is the "half-validation" of transactions; old clients and
    miners will check the hash in the scriptPubKey.@p{li)}

  @p{««}I also have some theoretical, "just makes me feel uncomfortable"
  reasons for disliking BIP 17: @p{»»}

  @p{««} @p{(li}@p{(link}OP_CHECKSIG@p{link)} feels like it was originally
  designed to be in the scriptPubKey@p{--} "scriptSig is for signatures."
  Although I can't see any way to exploit an OP_CHECKSIG that appears in
  the scriptSig instead of the scriptPubKey, I'm much less confident that
  I might have missed something. I'm much more confident that BIP 16 will
  do exactly what I think it will (because it is much more constrained,
  and executes the CHECKSIG exactly as if it appeared directly in the
  scriptPubKey).@p{li)}

    @p{(li}Changing from the scriptSig being just "push data onto the
    stack" to "do the bulk of verification" also makes me nervous,
    especially since nodes that relay transactions can add whatever they
    like to the beginning of the scriptSig before relaying the
    transaction. Again, I can't think of any way of leveraging that into
    an exploit, but the added complexity of code in the scriptSig and
    requiring OP_CODESEPARATORs in the right place makes me
    nervous.@p{li)}

    @p{(li}I've never liked OP_CODESEPARATOR@p{--} it is not like the
   other opcodes, the way it isn't affected at all by OP_IF and the way it
   'steps out' and causes the raw bytes of the transaction to be hashed.
   Nobody has been able to figure out how to use it, and the best guess is
   it is like your appendix: maybe useful in the past, but not useful now.
   Safer to get rid of it entirely, in my opinion.@p{li)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1409}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-21 01:24:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60014.msg704673@s{hash}msg704673
@section 3 {tx}

  @p{««}We need more Windows developers, by the way; if you know a lot
  about developing in C++ on Windows and want to (for example) create a
  Visual Studio project or resurrect makefile.vc or fix the build
  instructions if they're not right that'd be spiffy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1410}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-21 01:28:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=53650.msg704676@s{hash}msg704676
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nobody has written a Korean translation. If/when somebody does
  (join @s{(link)} if you want to help) you'd get the Korean translation.
  @p{»»}

  @p{««}An option to change the language in the GUI is a great idea.
  Somebody should do that.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1411}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-21 01:32:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60448.msg704690@s{hash}msg704690
@section 3 {tx}

  @p{««}If you don't want to change you can just ignore the new feature(s).
  There is zero risk with the proposed changes for anybody running old,
  un-hacked versions of bitcoin. @p{»»}

  @p{««}(if you are solo mining and hacked your version of bitcoin to
  accept 'non-standard' transactions then you @p{(it}could@p{it)} shoot
  yourself in your foot, but even that is unlikely). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1412}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-21 17:12:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg705543@s{hash}msg705543
@section 3 {tx}

  @s{quotedtext}

  @p{««} By the way... if there is no fully-functional reference
  implementation yet, you really shouldn't be putting "CHV" in your
  coinbases yet. The string in the coinbase really aught to mean "this
  code is all ready to support this feature," because full support from a
  majority of hashing power is what we want to measure. @p{»»}

  @s{quotedtext}

  @p{««} Imagine you're an early adopter. You ask people to send you money
  into your spiffy new ultra-secure wallet. @p{»»}

  @p{««}With BIP 16, transactions TO you will take longer to get into a
  block because not everybody is supporting the new feature. @p{»»}

  @p{««}But transactions FROM you will look like regular transactions, so
  the people you are paying won't have to wait. @p{»»}

  @p{««}That is not a big difference, but it is an advantage of the BIP 16
  approach. @p{»»}

  @s{quotedtext}

  @p{««} No, they are not evaluated in the same way. The bit of code in
  bitcoin transaction validation that makes me nervous is: @p{»»}

  @p{««}Code: txTmp.vin(nIn).scriptSig = scriptCode; ... in
      SignatureHash(), which is called from the CHECKSIG opcodes.
      scriptCode is the scriptPubKey from the previous (funding)
      transaction, txTmp is the transaction being funded. @p{»»}

  @p{««}This is the "Copy the scriptPubKey into the scriptSig before
  computing the hash that is signed" part of what OP_CHECKSIG does. @p{»»}

  @p{««}I like BIP 16 better than OP_EVAL/BIP 17 because BIP 16 does two
  complete validations, once with the scriptPubKey set to HASH160
  @p{lt}hash@s{gt} OP_EQUAL and then once again with the scriptPubKey set
  to (for example) @p{lt}pubkey@s{gt} OP_CHECKSIG. @p{»»}

  @p{««}BIP 16 essentially says "If we see a P2SH transaction, validate it,
  then treat it is a normal, standard transaction and validate it again."
  @p{»»}

  @p{««}BIP 17 will run OP_CHECKSIGs when it is executing the scriptSig
  part of the transaction, which is a completely different context from
  where they are executed for the standard transactions we have now. @p{»»}

  @p{««}Again, I can't see a way to exploit that but it makes me very
  nervous. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1413}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-23 21:59:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg709359@s{hash}msg709359
@section 3 {tx}

  @s{quotedtext}

  @p{««} BIP 16 explicitly states: @p{brk} "Validation fails if there are
  any operations other than "push data" operations in the scriptSig."
  @p{»»}

  @p{««}Let me try again for why I think it is a bad idea to put anything
  besides "push data" in the scriptSig: @p{»»}

  @p{««}Bitcoin version 0.1 evaluated transactions by doing this: @p{»»}

   @s{code}

  @p{««} That turned out to be a bad idea, because one person controls what
  is in the scriptPubKey and another the scriptSig. @p{»»}

  @p{««}Part of the fix was to change evaluation to: @p{»»}

   @s{code}

  @p{««} That gives a potential attacker much less ability to leverage some
  bug or flaw in the scripting system. @p{»»}

  @p{««}Little known fact of bitcoin as it exists right now: you can insert
  extra "push data" opcodes at the beginning of the scriptsigs of
  transactions that don't belong to you, relay them, and the modified
  transaction (with a different transaction id!) may be mined. @p{»»}

  @s{quotedtext}

  @p{««} Are you volunteering to make that happen? After working really
  hard for over four months now to get a
  @p{(it}backwards-compatible@p{it)} change done I'm not about to suggest
  an "entire network must upgrade" change... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1414}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-24 03:23:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg709832@s{hash}msg709832
@section 3 {tx}

  @s{quotedtext}

  @p{««} I try not to respond to trolls, but.... @p{»»}

  @p{««}Quit spreading FUD. If you think BIP 16 is terrible, please give a
  rational reason, beyond "It is a special case," which I have repeatedly
  responded to. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1415}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-24 21:51:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60950.msg711055@s{hash}msg711055
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. Old solo mining clients will produce perfectly valid blocks,
  unless they've been hacked to mine "non-standard" transactions. @p{»»}

  @p{««}There is a small risk that somebody ELSE will produce an invalid
  block, old solo mining clients will think it is valid, and will try to
  mine on top of it. But that's a small risk because we'll wait until a
  super-majority of the network supports p2sh before starting to reject
  any p2sh transactions. @p{»»}

  @p{««}So worst case scenario would be: @p{»»}

  @p{(li}  Somebody with a hacked bitcoind mines a block containing a
  valid-under-old-rules, invalid-under-new p2sh transaction.  @p{li)}

    @p{(li}@p{(li} Old miners try to build on it, but the majority of the
    network rejects it (there's a short block-chain split). @p{li)}

  @p{««}If an attacker could target just the p2sh-supporting nodes and
  denial-of-service enough of them to get p2sh support below 50%, then
  there could be a longer block-chain split. If you do the math, that's
  not as easy as it sounds (if p2sh support is at 80%, you'd have to knock
  out 60% of the supporting nodes@p{--} 20% of the original network would
  support, 20% wouldn't...). @p{»»}

  @s{quotedtext}

  @p{««} Don't do that, please. "Voting" with your coinbase should mean you
  actually do the extra validation required by p2sh, otherwise you're
  saying you support a feature when you really don't. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1416}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-24 22:02:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56969.msg711075@s{hash}msg711075
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}I'd love so see a bitcoin client with p2pool-technology built in;
  bring back the "generate coins" option! @p{»»}

  @p{««}But... that will take a while. If I was a pool operator, though,
  I'd be thinking about other bitcoin-related businesses where I could use
  my expertise (the pool operators deserve a lot of credit, they've had to
  deal with DOS attacks, keeping their wallets safe, servicing hundreds or
  thousands of customers banging on their servers constantly, etc). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1417}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 14:48:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61087.msg712138@s{hash}msg712138
@section 3 {tx}

  @p{««}So I'm trying to figure out why I'm so annoyed at
  I'm-sure-you-can-guess-who. @p{»»}

  @p{««}And I think I've figured it out@p{--} I think it is because I feel
  like I bend over backwards to be completely honest and open about
  potential flaws or problems with my ideas, and I'm completely honest and
  open about the fact that I'm human and I make mistakes. @p{»»}

  @p{««}And it seems like that's being leveraged to create fear,
  uncertainty and doubt. I say something like "there is a small risk
  that...", but I NEVER EVER hear even a hint that the "other side's"
  proposal might be anything but perfect. @p{»»}

  @p{««}Maybe I'm just too naive, and aught to get with the program and say
  that everything I do comes perfect, straight from God. People do tend to
  suffer from @p{(link}The Wise Leader Fallacy@p{link)}; maybe I should
  stop fighting against human nature and be more of a politician. @p{»»}

  @p{««}Ok, enough venting. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1418}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 15:00:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg712152@s{hash}msg712152
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's non-trivial to implement; it seems to me that a conscious
  decision by the miners/pools to support or not support is less work and
  safer. @p{»»}

  @p{««}Luke proposed something similar earlier, though; I'm surprised his
  patches don't implement it. @p{»»}

  @p{««}I like whoever proposed that the string in the coinbase refer to
  the BIP, in the future that's the way it should be done. @p{»»}

  @p{««} RE: schedules: @p{»»}

  @p{««}Deadlines, as we've just seen, have a way of focusing attention.
  OP_EVAL got, essentially, zero review/testing (aside from my own) until
  a month before the deadline. @p{»»}

  @p{««}It seems to me one-to-two months is about the right amount of time
  to get thorough review and testing of this type of backwards-compatible
  change. Longer deadlines just mean people get busy working on other
  things and ignore the issue. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1419}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 16:13:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg712245@s{hash}msg712245
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, it really isn't. @p{»»}

  @p{««}Here's a possible future implementation of IsStandard(): @p{»»}

   @s{code}

  @p{««} I like the idea of a future IsStandard() that allows more
  transaction types, but only if they're under some (sane) resource
  limits. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1420}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 17:50:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg712368@s{hash}msg712368
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh? GIT HEAD bitcoind supports import private key functionality:
  @p{»»}

  @p{««}Code: importprivkey @p{lt}bitcoinprivkey@s{gt} {label} @p{brk}
  Whether or not that's ever supported by the GUI is a different issue,
  and there I think we SHOULD be more concerned about people using the GUI
  shooting themselves in their feet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1421}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 17:55:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=54603.msg712377@s{hash}msg712377
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've been very clear about my top development priorities: @p{»»}

    @p{(li} 1. Network stability: DoS threats, scaling-up issues, etc. @p{li)}

   @p{(li} 2. Wallet security/backup. @p{li)}

  @p{««}I see everything else as lower priority; I want users to be
  confident that their bitcoins can't get stolen even if they slip up and
  open an attachment in Outlook that the aughtn't have opened before I
  want a downloads-the-entire-blockchain-in-10-seconds client with all
  sorts of other bells and whistles. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1422}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 19:20:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg712543@s{hash}msg712543
@section 3 {tx}

  @s{quotedtext}

  @p{««}Please explain to me how ANY of the proposals (the original
  OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change
  our minds and want to remove support" case? @p{»»}

  @p{««}Removing support for BIP 17 would be harder than removing support
  for BIP 16, because if the network doesn't support it @p{(bf}all@p{bf)}
  BIP 17 transactions can be stolen @p{(bf}as soon as they're
  broadcast@p{bf)}. @p{»»}

  @p{««}Imagine there are a bunch of un-redeemed BIP 17 transactions in the
  block chain and support for BIP 17 goes away. Every single one of them
  could be immediately redeemed by anybody. @p{»»}

  @p{««}The situation is better with BIP 16, because of the "half
  validation" done by old nodes. Admittedly not a lot better, but it is
  the "belt and suspenders" nature of BIP 16 that makes me prefer it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1423}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 19:46:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60984.msg712598@s{hash}msg712598
@section 3 {tx}

  @p{««}Decentralized systems often settle into some kind of "power law
  distribution." @p{»»}

  @p{««}For example, there's no central authority determining how large
  cities all over the world should be, and yet if you plot the size of
  cities you'll see that there are a few REALLY big ones, a bunch of
  medium sized ones, and a gazillion small ones. @p{»»}

  @p{««}Plot the size of the bitcoin mining pools and I think you'll see
  the same thing. @p{»»}

  @p{««}If there were no mining pools, then plot the hashing power of
  individual miners and I bet you'd see the same thing... (ArtForz used to
  be a significant fraction of mining power all by himself, for example)
  @p{»»}

  @p{««}I worry a lot more about incentives than I do size; if the
  "naturally big" players have the right incentives, then they're not bad
  for the network. So far, I think the incentives are working nicely. For
  example, people HAVE tried to knock out the big mining pools and
  exchanges using denial-of-service attacks, and the big mining pools and
  exchanges have (as far as I can tell) worked to fix that problem
  themselves. @p{»»}

  @p{««}PS: p2pool built into a bitcoin client is something I'd fully
  support, I think a lot of people would like a one-button "get a trickle
  of bit-pennies" option. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1424}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-25 21:25:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg712822@s{hash}msg712822
@section 3 {tx}

  @p{««}So you might have rumblings about changes to the network: OP_EVAL
  and BIP 16 and BIP 17 and multisig and P2SH, and you wonder what the
  heck is going on. @p{»»}

  @p{««}Here's my view; I'll try not to get too technical. @p{»»}

  @p{««}First, the feature: @p{»»}

  @p{««}I want more secure wallets. There's unanimous agreement among
  developers that the easiest, fastest way to get there is with
  "multi-signature transactions" @p{--} bitcoins that require approval
  from more than one person or device to spend. @p{»»}

  @p{««}For example, a future version of Bitcoin-Qt might know how to talk
  to an app running on your mobile phone. When you send bitcoins, it would
  provide one signature, but it would have to ask your phone for approval
  and the other signature. That way even if your computer gets compromised
  by malware your bitcoins absolutely positively cannot be stolen, since
  the best the malware could do would be to ask your phone to approve the
  "Send the bad guys bitcoins" transaction. @p{»»}

  @p{««}The bitcoin network protocol already mostly support multi-signature
  transactions, although they're considered "non-standard" right now. Part
  of what is going in is making them standard. That's not controversial.
  @p{»»}

  @p{««}What @p{(bf}is@p{bf)} causing all the discussion is how to support
  sending coins into one of these new, spiffy, secure wallets. There is
  rough consensus that the best way to do that right now is with a new
  type of bitcoin address; I say "rough consensus" because in a perfect
  world some people think that there wouldn't be bitcoin addresses visible
  to users at all. And I say "right now" because we don't live in a
  perfect world, and there are no proposals for how, exactly, to replace
  bitcoin addresses with something better. @p{»»}

  @p{««}Part of the controversy is whether really long bitcoin addresses
  would work@p{--} would it be OK if the new bitcoin addresses were really
  long and looked something like this: @p{»»}

    @p{(li}57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
  @p{li)} (or possibly even longer) @p{»»}

  @p{««}I've argued no: past 70 or so characters it becomes a lot harder to
  copy and paste, a lot harder to scan an address with your eyes to see if
  you're paying who you think you're paying, harder to create a readable
  QR code, harder to upgrade website or database code that deals with
  bitcoin addresses, etc. There is rough consensus that very-long
  addresses are not workable. @p{»»}

  @p{««}So: there are three proposals on how to support short
  multisignature addresses@p{--} BIP 12, 16, and 17. @p{»»}

  @p{««}I withdrew BIP 12 (also known as "OP_EVAL") because I try to be
  extremely conservative when it comes to changes to core Bitcoin, and I
  think BIP 16 is a safer way to go. @p{»»}

  @p{««}Luke Dashjr liked OP_EVAL, really doesn't like BIP 16, and came up
  with BIP 17, which solves the same problem in a different way. I still
  like BIP 16 best, because I think it is the most conservative, safest
  solution. The number of people who understand the guts of Bitcoin well
  enough to have an informed opinion about which is better is pretty darn
  small, but I think the controversy is really about how conservative we
  aught to be. @p{»»}

  @p{««}All of the BIP 12/16/17 stuff is mostly engineers arguing over
  whether it is better to use a nail, a screw, or glue to put two pieces
  of wood together. Any of the solutions would work, and ordinary users
  wouldn't notice any difference; you'll still (eventually) get spiffy,
  more secure wallets. @p{»»}

  @p{««}(don't take the analogy too far, in this case using a nail AND a
  screw AND some glue to be extra safe isn't an option). @p{»»}

  @p{««}How dangerous is all this? Is the bitcoin network in danger of
  falling apart one of these BIPs is adopted? @p{»»}

  @p{««}The worst-case scenario for all of this stuff (including the
  non-controversial support of multisignature transactions as "standard")
  is that some bug will slip by, and an attacker will figure out a way of
  getting all the nodes running the new software to crash or misbehave.
  I'm working hard to prevent that from happening@p{--} I've been writing
  "unit tests" and "fuzzing tools" and have been getting other developers
  to look really hard at the code. I strongly believe that the new feature
  is worth the (small) risk, and that even in the worst-case scenario the
  consequences are not catastrophic (we'd just fix the bug and come out
  with a new release; everybody still running old code would continue to
  confirm transactions and create blocks while the early adopters were
  busy downloading and installing the fixed software). @p{»»}

  @p{««}The bitcoin network is NOT in danger of falling apart if any of
  these are adopted; they are all backwards-compatible, so old software
  will continue to work exactly as before. @p{»»}

  @p{««}Some footnotes (and sorry for making this so long): @p{»»}

  @p{««}I concentrated on multisignature transactions for secure wallets,
  but they're useful for several other things, including escrow
  transactions and "emergency offline backup keys" for wallet backups.
  @p{»»}

  @p{««}I've set an arbitrary deadline of February 1'st for deciding
  whether or not to "turn on" the new
  short-multisignature-bitcoin-address-support feature, mostly because
  deadlines are the only way I know to actually get people to pay
  attention. If you read the BIPs, those deadlines are designed to be
  flexible, so if there is NOT a majority of support or "we" think that
  not enough time has gone by or enough testing has been done they can
  (and will) be slipped. @p{»»}

  @p{««}Right now, it looks like one person/pool (Tycho/deepbit) has enough
  hashing power to veto any change. I believe Tycho liked, and planned to
  support, the original OP_EVAL proposal, but doesn't like/support either
  BIP 16 or BIP 17 (he does like/support BIP 11, the
  multisignature-as-standard-transactions part of all this), so unless he
  changes his mind or there is a mass exodus from his pool short,
  multisignature bitcoin addresses will have to wait. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1425}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 00:01:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61087.msg713112@s{hash}msg713112
@section 3 {tx}

  @s{quotedtext}

  @p{««} I suppose I could have posted to the general Bitcoin Talk, but I
  didn't think that kind of low-level "plumbing" would be of general
  interest, any more than the average bitcoin user would care or notice a
  bunch of other low-level "plumbing" changes that are being made (I've
  got a patch pending that a certain-somebody doesn't like because it
  tightens up the definition of a "standard" transaction; I expect that if
  I pull that patch he'll start screaming that I'm wrecking future network
  flexibility all because I'm a big old worry-wart). @p{»»}

  @p{««}I @p{(bf}did@p{bf)} post to the Mining/Pools forum a couple of
  months ago looking for feedback because miners/pool operators are the
  people who are "voting" on the original proposal: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}msg604435@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1426}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 01:06:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg713248@s{hash}msg713248
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bitcoin addresses today correspond to one @p{(ul}public key@p{??)}
  in your wallet. @p{»»}

  @p{««}Signatures enter the picture when you spend the bitcoins sent to an
  address; your private key is used to generate the right digital
  signature, proving that you actually have that key. @p{»»}

  @p{««}BIP 16/17 will enable bitcoin addresses that are associated with
  more than one public key. Your wallet will know both public keys, but
  will only know ONE of the private keys needed to spend the bitcoins
  (your phone or a "wallet protection service" will keep the other private
  key safe). @p{»»}

  @p{««}So when sending coins, your wallet will provide one signature for
  the private key that it knows, the other required signature must come
  from whatever device is holding the other private key. @p{»»}

  @p{««}The public keys aren't just strung together in a row, but are
  combined using a secure hashing algorithm (the same algorithm that is
  used to associate public keys with the bitcoin addresses we're all using
  today). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1427}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 14:17:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg714356@s{hash}msg714356
@section 3 {tx}

  @s{quotedtext}

  @p{««} I believe that without a deadline nothing would get done. @p{»»}

  @p{««}We could talk and argue and discuss for six months trying to find
  the perfect solution, and there would still be people saying that we
  need another six months to argue and discuss some more. @p{»»}

  @p{««}In fact, us developers HAVE been discussing and arguing about this
  for over six months now; this whole thing started with an impromptu
  brainstorming session at the first Bitcoin Conference in New York. @p{»»}

  @p{««}As for this upgrade being "secretive" : huh? It certainly
  isn't/wasn't a secret among the developers, and until the developers
  came to rough consensus (and I believe there IS rough consensus, despite
  what Luke claims) I didn't think non-developers would be interested in
  the technical details. @p{»»}

  @p{««}From some of the reactions in this thread, I think I was
  right@p{--} most people don't care whether we use nails or screws or
  glue to build a better wallet. @p{»»}

  @p{««}RE: rumors that I'm doing this for some personal reason: 100%
  untrue. I want a solution because it will make Bitcoin better sooner.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1428}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 14:37:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg714404@s{hash}msg714404
@section 3 {tx}

  @p{««}I want to try to clear up two misconceptions: @p{»»}

    @p{(li} 1. The original implementation of OP_EVAL was not
    "exploitable", but it did have bugs. @p{li)}

    @p{(li} 2. The Feb. 1 deadline was explicitly designed to be a "soft"
    deadline; here is what BIP 16 says about it: @p{li)}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1429}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 17:21:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61248.msg714655@s{hash}msg714655
@section 3 {tx}

  @p{««}I just had a great discussion with a developer who urged me to
  write a "big picture" technical post about BIP 16. So: @p{»»}

  @p{««}First, I think a good design approach is to be clear about what you
  are trying to accomplish and think about what the ideal solution, if
  there were no constraints like backwards compatibility, would look like.
  @p{»»}

  @p{««}The big picture goal has always been: short, multisignature bitcoin
  addresses (BIP 13). @p{»»}

  @p{««}The ideal solution would be to split scriptSig/scriptPubKey into
  three parts: @p{»»}

  @p{««}signatures, redemption script, and redemption script hash. @p{»»}

  @p{««}The sender would just provide the script hash, the receiver would
  provide the script and signatures to sign them over to somebody else.
  @p{»»}

  @p{««}Ideally, the redemption script hash would be include a version or
  'hash type' byte, so in the future if RIPEMD160(SHA256()) was ever
  considered insecure a smooth upgrade could happen. @p{»»}

  @p{««}That's the ideal solution. I think all bitcoin transactions should
  have been done that way from the start, but it is what it is. Now we
  have to compromise, because one of the design constraints is backwards
  compatibility@p{--} we are not going to replace scriptSig/scriptPubKey
  with something else and require everybody to upgrade all at once. @p{»»}

  @p{««}OP_EVAL tried to do too much, in my opinion. It enabled all sorts
  of nifty things, but we made the mistake of losing sight of what we were
  trying to accomplish. @p{»»}

  @p{««}BIP 16, in my view, meets the goal and (importantly!) @p{(bf}does
  nothing more@p{bf)}. I think of it as implementing the ideal three-way
  split in as simple and safe way as possible: @p{»»}

  @p{««}signatures: all the items except the last pushed onto the stack by
  the scriptSig @p{brk} redemption script: the last item pushed onto the
  stack by the scriptSig @p{brk} redemption script hash: the scriptPubKey
  @p{»»}

  @p{««}It is pretty darn close to what I think would be the ideal
  solution. It even has a byte at the beginning of the redemption script
  hash that specifies what hash type to use (OP_HASH160) ! @p{»»}

  @p{««} @p{hrule} @p{brk} That's all why I like BIP16 better than OP_EVAL.
  I've written quite a lot here on the details of why I prefer BIP 16 to
  BIP 17, but, fundamentally, I believe that BIP 16 is a more conservative
  solution that is less likely to have an "darn, I didn't see that coming"
  bug. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1430}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 20:01:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61172.msg714957@s{hash}msg714957
@section 3 {tx}

  @s{quotedtext}

  @p{««} Let me count the ways: @p{»»}

    @p{(li} 1. You must explicitly choose a username and password; you
    must have enough tech know-how to find your bitcoin.conf directory or
    run with -rpcpasswrod= options. @p{li)}

    @p{(li} 2. If you choose a short password, then every failed access
    attempt DOES trigger a timeout. @p{li)}

    @p{(li} 3. You must explicitly tell bitcoin to listen for connections
    from IP addresses other than localhost, using the rpcallowip= option.
    @p{li)}

    @p{(li} 4. You must open a hole in your firewall that lets any
    arbitrary IP address through to your rpcport. @p{li)}

  @p{««}I'm sorry you lost 75 bitcoins, but you really made a LOT of
  mistakes. Adding more layers of protection to the RPC interface isn't
  high on the development priority list, but if anybody wants to volunteer
  to keep track of number of failed RPC authentication attempts over time
  then be my guest and write a patch. Just be sure it isn't vulnerable to
  denial-of-service attacks by people deliberately generating failed login
  attempts. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1431}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 20:16:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61235.msg714989@s{hash}msg714989
@section 3 {tx}

  @s{quotedtext}

  @p{««}Like @p{(link}this one@p{link)}? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1432}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 22:19:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61294.msg715284@s{hash}msg715284
@section 3 {tx}

  @s{quotedtext}

  @p{««} Did you read BIP 16? @p{»»}

  @s{quotedtext}

  @p{««} So there is no manipulation allowed AT ALL. @p{»»}

  @s{quotedtext}

  @p{««} A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed
  in the scriptSigs and scriptPubKeys of transactions in any given block.
  @p{»»}

  @p{««}We had a block earlier this month with 1,8000 scriptSigs, so I
  think we are uncomfortably close to that limit. @p{»»}

  @p{««}BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more
  of them are allowed. @p{»»}

  @s{quotedtext}

  @p{««} At the very least BIP 17 is harder to test@p{--} Luke had to test
  on the main network because I was naughty and wrote and ran a
  BIP-17-transaction-stealing bot (sorry, I couldn't resist). @p{»»}

  @s{quotedtext}

  @p{««} I have zero commercial interest; I am not being paid by anybody
  for anything right now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1433}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 22:23:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg715297@s{hash}msg715297
@section 3 {tx}

  @s{quotedtext}

  @p{««}I apologize@p{--} I did not mean to attack you, I thought I stated
  nothing but facts. I am also sorry I didn't speak up about some of the
  things that were said about you earlier in this thread (e.g. suggesting
  an attack on your pool is NOT cool) but I don't have time to read every
  forum post as soon as it is posted... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1434}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 22:51:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61172.msg715344@s{hash}msg715344
@section 3 {tx}

  @s{quotedtext}

  @p{««} I apologize for coming across as harsh, it has been a hard couple
  of weeks. @p{»»}

  @p{««}And the reason it has been a hard couple of weeks is because I'm
  working really hard to try to get support for multisignature wallets...
  which would have prevented your loss (assuming you were using a
  multisignature-protected wallet). @p{»»}

  @p{««}The hacker would have been able to ask your bitcoind to send him
  your coins, but you would have got a confirmation on your cell phone (or
  SMS or email with a one-time-PIN or whatever) and realize immediately
  that you'd been hacked. @p{»»}

  @p{««}Or, in other words: I've been working really hard trying to get a
  solution for the bigger problem of insecure computers, because I really
  do care about the "flock." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1435}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-26 23:56:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61017.msg715448@s{hash}msg715448
@section 3 {tx}

  @p{««}LOL! I gotta stop shaving and start working on that nifty 'stash !
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1436}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 02:58:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg715828@s{hash}msg715828
@section 3 {tx}

  @s{quotedtext}

  @p{««}We all learn from our mistakes. @p{»»}

  @p{««}Would you be willing to write an "informational BIP" describing how
  to do a rollout right in the future? @p{»»}

  @p{««}I'm terrible at that kind of "first we'll need to get buy-in from
  groups X, Y, and Z by doing A, B, and C, then each of those groups will
  elect representatives who will have three days to agree to a schedule,
  which will be announced blah blah blah blah" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1437}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 03:38:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg715924@s{hash}msg715924
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).
  See BIP 0001 for the process.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1438}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 17:35:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg716946@s{hash}msg716946
@section 3 {tx}

  @s{quotedtext}

  @p{««}Testing is actually one of the reasons I don't like BIP 17; it is
  harder to test, because it is much easier to steal BIP-17 transactions
  if the network hasn't yet upgraded (Luke has had to test BIP 17 on the
  main network instead of testnet because I wrote a BIP-17-stealing robot
  and ran it on testnet). @p{»»}

  @p{««}I've spent the last couple of days running "transaction fuzzing"
  tests against both the new BIP 16 code and old clients; so far it has
  turned up no problems. "Fuzzing" means throwing lots and lots of random
  inputs at a program and making sure it deals with them properly; it is
  another good way of finding the "what do you know, we didn't think of
  that..." bugs. @p{»»}

  @p{««}The fuzzing tool is here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Also RE: ghastly exploits: @p{»»}

  @p{««}Satoshi himself made changes to the way the scripting language
  works after a series of 'ghastly exploits' were discovered back in 2010
  after the first slashdotting. I'm so stubbornly against BIP 17 because
  it basically reverts one of the changes he made (separating execution of
  scriptSig and scriptPubKey@p{--} take that discussion to another thread
  in Dev&amp;Tech if you want to argue more about it, please). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1439}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 19:23:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=23768.msg717128@s{hash}msg717128
@section 3 {tx}

  @s{quotedtext}

  @p{««} @p{lt}begin troll@s{gt} @p{»»}

  @p{««}No it is not! BIP 17 is bad for the network and will give you
  herpes! @p{»»}

  @p{««}@p{lt}end troll@s{gt} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1440}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 19:29:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61400.msg717140@s{hash}msg717140
@section 3 {tx}

  @p{««}(channelling my inner CoinHunter): @p{»»}

  @p{««}It is @p{(it}@p{(bf}SIMPLE ECONOMICS@p{bf)}@p{it)}, people! @p{»»}

  @p{««}price = function(supply,demand) @p{»»}

  @p{««}So to create more demand, just fix the price and the supply!
  Easy-peasy! @p{»»}

  @p{««}(ok, done, back to reality) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1441}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 21:01:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61429.msg717353@s{hash}msg717353
@section 3 {tx}

  @p{««}A few of the big mining pools have started supporting BIP 16, and I
  feel pretty confident that they've shaken out any major bugs. @p{»»}

  @p{««}If you'd like to jump on the bandwagon, backported code for BIP 16
  is available at: @p{»»}

    @p{(li}@s{(link)} @p{li)} ... in the "p2sh_backport" and
  "p2sh_backport_vinced" branches. @p{»»}

  @p{««}Backports are available for all releases from bitcoin version
  0.3.19 forward; for example if you're running code forked from the
  0.3.24 release you would: @p{»»}

   @s{code}

  @p{««} The "vinced_mergedmine" tags are for if you are using Vince's
  'getauxwork' patch/branch for merged mining (based on bitcoin version
  0.3.24). @p{»»}

  @p{««}If you're running latest&amp;greatest or are willing to upgrade to
  the latest&amp;greatest, BIP 16 support is already in @s{(link)} @p{»»}

  @p{««} Finally, if you do decide to support BIP 16, upgrade your code,
  and start mining with it, let me know and I'll be happy to thank you
  publicly in my signature (offer good until I run into the
  300-characters-in-the-signature forum limit).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1442}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-27 22:15:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60433.msg717473@s{hash}msg717473
@section 3 {tx}

  @s{quotedtext}

  @p{««} Just FYI: I contacted the top ten mining pools (as listed in the
  stickied threads in the Mining Pools subforum) directly via email way
  back in October, copied the email to them in the Mining Pools forum, and
  kept them 'in the loop' on all of this. @p{»»}

  @p{««}I probably should have posted all of my followup emails to them in
  the Mining Pools forum, also; as I said, I'm terrible at that kind of
  "keep track of who you've told what and make sure you've got 'buy-in'
  from X Y and Z" thing. @p{»»}

  @p{««}I think my only really major blunder was being too stubborn about
  inserting some wording into BIP 16 that Luke wanted inserted; I let my
  emotions cloud my judgement. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1443}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-28 01:12:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=60948.msg717894@s{hash}msg717894
@section 3 {tx}

  @p{««}Yes, you will confuse the GUI if you send coins to 'change'
  addresses. @p{»»}

  @p{««}My advice would be "don't do that." @p{»»}

  @p{««}Thanks very much for helping to test, though, it is very
  appreciated! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1444}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-28 17:08:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61429.msg718879@s{hash}msg718879
@section 3 {tx}

  @p{««}You know how I say "I make mistakes, don't trust me" ... @p{»»}

  @p{««}A bug in my code is dropping transaction fees from the block
  reward. Simple to fix, and obvious in hindsight; I will be personally
  reimbursing everybody who got bit by this bug by finding the blocks
  affected by this, figuring out what transaction fees the creators SHOULD
  have received, and sending that number of bitcoins to the block-award
  address. @p{»»}

  @p{««}Backports and the main git HEAD tree have been patched with the
  fix. @p{»»}

  @p{««} @p{hrule} On a higher level: @p{»»}

  @p{««}There is obviously not going to be 50+% blockchain support for BIP
  16 on Tuesday; I'm going to start conversations on how to move forward.
  @p{»»}

  @p{««}And there has obviously not been enough testing of the BIP 16 code.
  Getting people to thoroughly test things BEFORE code makes it into the
  main tree has been a chronic problem, I'd appreciate ideas on how to
  avoid this kind of annoying, time-wasting "it's ready"/"oops, found a
  bug"/"it's fixed"/"wait, no, somebody found another bug" thing in the
  future. I've been unsuccessful finding the kind of QA (quality
  assurance) person who can both do the QA and do the fundraising
  necessary so they get paid. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1445}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-29 15:02:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61429.msg720406@s{hash}msg720406
@section 3 {tx}

  @s{quotedtext}

  @p{««} The fees were 0 all the time, that was the bug.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1446}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-29 16:41:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61705.msg720564@s{hash}msg720564
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is completely artificial urgency, so a decision is reached and
  implemented in a reasonable amount of time. @p{»»}

  @p{««}When I set the deadline, I had no idea Luke would: @p{»»}

    @p{(li}a) Decide that a bugfix 0.5.2 release was a good idea. I
    thought the minor bugfixes weren't worth taking the time to make a
    release but arguing with Luke is like arguing with a brick wall, so I
    went "meh, whatever." @p{li)}

    @p{(li}b) Propose BIP 17 and go on a war against BIP 16. @p{li)}

  @p{««}Both of those distracted from implementation and testing of BIP 16.
  @p{»»}

  @p{««}But what's past is past, the question is what do do from here; I'm
  planning on starting that discussion in the Dev&amp;Tech forum tomorrow.
  @p{»»}

  @p{««}PS: RE: risk: the risks of either proposal to the overall health of
  the bitcoin network are small.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1447}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 14:46:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61900.msg722227@s{hash}msg722227
@section 3 {tx}

  @p{««}So the SolidCoin folks have been creating 1-post locked threads
  announcing stuff. @p{»»}

  @p{««}Putting aside how you feel about SolidCoin, I wonder what other
  people think about that practice in general. It seems to me to go
  against the purpose of "Forums" @p{--} seems to me the whole point is
  discussion. If you don't want discussion, then buy an ad or publish
  information on your website. @p{»»}

  @p{««}Seems to me locking threads should be a last resort instead of
  "I'll just lock every thread I make to keep out the trolls." @p{»»}

  @p{««}I'm going to lock this thread now because I think some people will
  disagree with me. @p{brk} (KIDDING, JUST KIDDING) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1448}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 15:03:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61836.msg722253@s{hash}msg722253
@section 3 {tx}

  @s{quotedtext}

  @p{««}So far, I think the pace of technological change has outrun
  governments' ability to figure out how to use it to exert control. @p{»»}

  @p{««}Maybe governments will get more nimble, but I'm going to continue
  betting that entrepreneurs and individuals will continue to widen the
  gap between the new freedoms that technology enables and what the law
  allows. @p{»»}

  @p{««}RE: multisignature transaction dangers: I'm completely convinced
  the (large, practical) benefits far outweigh the (small, theoretical)
  risks that it'll be abused by some repressive government(s). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1449}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 17:35:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61836.msg722480@s{hash}msg722480
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, that's the use-case I care most about @p{--} you have control
  over all of your keys, you just put them in multiple places so if you
  lose control of (say) your computer you don't lose your bitcoins. @p{»»}

  @p{««}But there are other use-cases, like you agreeing to let the
  government control half the keys, so the government can "guarantee" the
  transactions, etc. I can imagine the PR campaign: "It is just like
  Federal Deposit Insurance (FDIC), only for Bitcoin!" @p{»»}

  @p{««}I don't think that will ever happen, though. I know I wouldn't
  trust the government to keep the keys to my money safe and secure, I
  don't think most people would, either. More likely is most people will
  trust banks to hold half the keys, and the governments will then
  regulate the banks like they do today to get information about who is
  paying who for what.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1450}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 17:49:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61922.msg722508@s{hash}msg722508
@section 3 {tx}

  @p{««}BIP 16 (or 17) will not meet their initial "go/no-go" deadlines.
  You can see the state of support here: @s{(link)} @p{»»}

  @p{««}That's OK, that's why the deadlines were structured the way they
  are; in the past, Satoshi made changes like this by simply changing the
  code and then expecting everybody to upgrade. This is the first time
  we've used a more open, community-driven process. @p{»»}

  @p{««}So, since we'll miss the deadline, the question is: what next? To
  focus discussion, here are two straw-man proposals that y'all can agree
  or disagree with; I'll go along with whatever consensus arises over the
  next couple of days: @p{»»}

  @s{quotedtext}

  @s{quotedtext}

  @p{««}@p{hrule} On the subject of testing... I've created a wiki page to
  record QA (quality assurance) testing that has been done on BIP 16. If
  you can help test, or have been testing/deploying, then please add to
  this page: @s{(link)} @p{»»}

  @p{««}As always, (on-topic) discussion, feedback, etc. is very welcome.
  If we can, I'd like to move past the "we dont' need to do ANYTHING"
  arguments, there is clearly rough consensus (with notable exceptions)
  that a short-bitcoin-address solution is needed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1451}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 17:50:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58637.msg722516@s{hash}msg722516
@section 3 {tx}

  @p{««}RE: rushing: @p{»»}

  @p{««}I'm starting a discussion on how not to rush here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1452}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 17:52:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61429.msg722518@s{hash}msg722518
@section 3 {tx}

  @p{««}I've started a discussion on BIP 16/17 support moving forward
  (including trying to improve the testing process) here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1453}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 17:54:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg722519@s{hash}msg722519
@section 3 {tx}

  @p{««}I've started a discussion on BIP 16/17 support moving forward
  (including trying to improve the testing process) here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}(please reply there so the discussion stays mostly in one place)
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1454}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 22:24:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61429.msg722975@s{hash}msg722975
@section 3 {tx}

  @s{quotedtext}

  @p{««} Transaction sent:
  @p{(link}2d3006cf1e16cb9f4097894fdaa0739c66d38eb9e0356be3fd8daf63810cf375@p{link)}
  @p{»»}

  @p{««}I wrote some code that found all blocks with "/P2SH/" in their
  coinbase that did not include transaction fees in the block reward. I
  extracted the block reward payment address (or addresses, if it was a
  p2pool block) and reimbursed those addresses. @p{»»}

  @p{««}If the amount would be less than 0.0011 bitcoins, then I rounded
  the amount awarded up to 0.0011. Just because eleven is my favorite
  number (well, and because I like the idea of rewarding p2pool users, I
  think p2pool is neat).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1455}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-30 22:42:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61705.msg723015@s{hash}msg723015
@section 3 {tx}

  @p{««}For context: makomk is the creator of CoiledCoin, a bitcoin
  alternative: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}And RE: creating bots: I created a BIP-17-stealing bot because it
  was really easy (took about 10 minutes of hacking). A BIP-16-stealing
  bot would be a lot harder (because it would have to 'lie in wait' until
  the sender was redeeming the coins, and then race to relay/mine a
  'stealing' version of the transaction before the rest of the network
  mined the original). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1456}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 13:26:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg724040@s{hash}msg724040
@section 3 {tx}

  @p{««}Thanks to midnightmagic who directed me to this very helpful video
  about identifying and then dealing with "poisonous people" in open
  source software projects: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Advice on disinfecting: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Watch the whole thing for examples of "poisonous person" behavior,
  like repeatedly flooding mailing lists/forums with their opinion or
  comments, not listening to the opinion of others, or making sweeping
  "the world will end if..." statements about the project. @p{»»}

  @p{««}I'll be blunt: I think Luke Dashjr fits the definition of a
  poisonous person, and I think Bitcoin would be better without him. At
  the very least, we wouldn't be creating two BIPs for every technical
  issue, one for Luke and one for the rest of us (see BIP 16/17, and now
  we have BIP 20/21, too). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1457}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 13:49:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg724074@s{hash}msg724074
@section 3 {tx}

  @p{««}bittenbob: @p{»»}

  @p{««}You replied 3 minutes after I posted. You obviously didn't watch
  the video link I posted. @p{»»}

  @p{««}At that link, two experienced subversion (another successful open
  source project) developers talk about what to do if somebody in your
  open source community makes it impossible to have unity and agreement.
  @p{»»}

  @p{««}You say "we need to get back to unity" @p{--} I agree. That is why
  Luke must go. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1458}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 15:41:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg724221@s{hash}msg724221
@section 3 {tx}

  @p{««}RE: debating ideas rather than people: I've tried very hard to do
  that. @p{»»}

  @p{««}I said last year when I reluctantly agreed to function as the lead
  core bitcoin developer that I have zero experience leading open source
  projects. But I try to do my due-diligence and learn from the experience
  of other successful projects. @p{»»}

  @p{««}The "aha" moment for me yesterday is the point in the video that I
  linked to, where the advice is to evaluate whether or not somebody
  causing issues for a project (whether intentional or not) is a net
  positive or negative to the project, and if they're "more trouble than
  they're worth" get them out of the project. @p{»»}

  @p{««}This isn't about BIP 16 versus BIP 17, this is about one person
  draining the rest of the development team with nagging, idealogical
  rigidity, and holy wars against "impure" ideas. @p{»»}

  @p{««}I try very hard to consider that maybe I'm wrong, but I think the
  evidence is clear. @p{»»}

  @p{««}You might also argue that the subversion people take the wrong
  approach, in which case please send me a link to some other open source
  project that has dealt with the issue in a different/better way. @p{»»}

  @p{««}I thought carefully about where to start this, and decided I might
  as well start it in the most public bitcoin discussion forum, because I
  think if I started it anywhere else it would eventually just appear here
  as "There's a Secret Conspiracy Started By Gavin To Oust A Valued
  Developer!" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1459}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 15:52:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61575.msg724235@s{hash}msg724235
@section 3 {tx}

  @s{quotedtext}

  @p{««} You understand wrong. @p{»»}

  @p{««}BIP 16 recognizes a certain pattern of bytes, and says "If you see
  those bytes, then the script will be provided by the person who has the
  coins instead of the sender (the sender just provides a secure hash of
  that script)." @p{»»}

  @p{««}The script that is provided is then used EXACTLY as if it was a
  "normal" sender-provides-the-script transaction. @p{»»}

  @p{««}BIP16 is the most conservative possible solution to the problem we
  want to solve. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1460}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 16:48:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg724306@s{hash}msg724306
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, exactly. At some point you have to say "enough is enough, I'm
  not going to let this person derail the project any more going forward."
  @p{»»}

  @p{««}I'm saying that point is right now; see the unproductive, one-sided
  argument about @p{(link}BIP 20 versus BIP 21@p{link)} on the
  bitcoin-development mailing list that is re-hashing a wiki editing war
  that "the rest of us" just gave up on a year ago for the latest example.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1461}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-01-31 19:06:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62068.msg724508@s{hash}msg724508
@section 3 {tx}

  @p{««}FYI: I pulled: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... which will likely result in a testnet blockchain split on
  February 15'th. I hadn't pulled before because I was busy with other
  things. The @p{(link}testnet faucet@p{link)} bitcoind will be updated in
  the next day or two. @p{»»}

  @p{««}See @p{(link}this thread@p{link)} for the design discussion. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1462}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 13:24:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg725871@s{hash}msg725871
@section 3 {tx}

  @p{««}I moved Casascius' proposal ("BIP 22") to the Dev&amp;Tech forum, I
  will respond there.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1463}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 13:28:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62181.msg725876@s{hash}msg725876
@section 3 {tx}

  @p{««}STOP IT. JUST STOP IT. @p{»»}

  @p{««}BIP 16 has overwhelming support, it will be the solution. @p{»»}

  @p{««}Casascius: please read BIP 0001 for the process to get assigned a
  BIP number. The process is not "create a page on the wiki." @p{»»}

  @p{««}As for the proposal itself: No. @p{»»}

  @p{««}You are proposing a non-backwards-compatible change, which would
  mean a "hard" blockchain split. @p{(bf}Everybody@p{bf)} agrees that is a
  bad idea. The confusion and potential for hacks if a significant
  fraction of bitcoin users were on a separate chain is massive; you gloss
  over all of that in your proposal. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1464}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 14:31:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61922.msg725952@s{hash}msg725952
@section 3 {tx}

  @p{««}OK, it has been a couple of days and the general consensus seems to
  be a 'rolling' two-week window, with no "below 20%" rule. @p{»»}

  @p{««}I don't think there is any need for a two-week email discussion
  period among those familiar with the guts of Bitcoin, we've already
  spent months discussing the options and the consensus for BIP 16 is
  clear (see @p{(link}the tally here@p{link)}). @p{»»}

  @p{««}It is time to call it settled and move on to bigger and better
  things, like what protocol to use when a client needs to gather
  signatures (REST? JSON? http? https? something else?). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1465}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 14:37:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62181.msg725958@s{hash}msg725958
@section 3 {tx}

  @p{««}I apologize for the shouting, it's been a hard couple of weeks. And
  thanks for the support. @p{»»}

  @p{««}Very quickly, the problem with any chain split is double spends. An
  attacker can spend his bitcoins twice, once using CHECKSIGEX and some
  script instead of a public key. They can wait for the coins to confirm
  on the "new" chain, and then they can spend the coins again, using
  CHECKSIG, on the old chain. @p{»»}

  @p{««}The result would be massive confusion and chaos as those "old"
  users slowly upgraded and then found their wallets had NEGATIVE balances
  after the upgrade. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1466}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 18:03:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=61125.msg726268@s{hash}msg726268
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, you don't have to upgrade your client to receive coins from
  somebody using a BIP 16 multisignature wallet.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1467}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 18:40:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62181.msg726324@s{hash}msg726324
@section 3 {tx}

  @p{««}No, bad idea, two chains cannot peacefully coexist for more than a
  few dozen blocks, they would eventually make a complete mess out of
  users' wallets. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1468}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 19:45:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62204.msg726436@s{hash}msg726436
@section 3 {tx}

  @s{quotedtext}

  @p{««} They just keep running the code they've been running. It will
  reject the 'bad' blockchain being produced by 95% of the miners, and
  accept the 'good' chain being produced by the other 5%. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1469}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-01 21:48:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62204.msg726653@s{hash}msg726653
@section 3 {tx}

  @p{««}RE: lightweight versus heavyweight clients: @p{»»}

  @p{««}First: lightweight clients (like Multibit) that don't store the
  entire blockchain must rely on the rest of the network to confirm that
  transactions are valid. They can't check for themselves (this is true
  today, and BIP 16 doesn't change that at all). @p{»»}

  @p{««}Full clients do check, but it is still not safe for them to accept
  0- or 1-confirmation transactions; an attacker might be sending them an
  attempted double-spend (and the network might be still be trying to
  figure out which 'side' of the double-spend will win). That is also true
  today. @p{»»}

  @p{««}"Backwards compatibility" means that all valid transactions created
  by the new software will be accepted as valid transactions by the old
  software. @p{»»}

  @p{««}But, after BIP 16 is supported by a majority of the network, there
  could exist transactions that the old software considers valid but the
  new software rejects as invalid. @p{»»}

  @p{««}So... does BIP 16 make things riskier for people running old
  software? Yes, a tiny bit, in the very particular case of 1-confirmation
  transactions. And that particular attack requires that the attacker
  manage to mine a block that they know will be found invalid (which is
  expensive). Again, if you get bitcoins from somebody you do not trust
  then you should wait until they have 3 or more (6 if you want to be
  extremely safe) confirmations before considering the payment final.
  @p{»»}

  @p{««}If you want all the technical details of why BIP 16 does NOT
  increase the risk for 0-confirmation transactions but does for
  1-confirmation transactions... ask me another day (it has to do with how
  the old software recognizes "Standard" transactions and won't even show
  you transactions it doesn't recognize).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1470}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-02 14:17:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=59985.msg727688@s{hash}msg727688
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, bitcoind is solid as a rock, both with and without the BIP 16
  patches applied. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1471}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-03 12:37:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62037.msg729246@s{hash}msg729246
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. Who wants to volunteer to do the fundraising and
  organize this, and let me know how I can help? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1472}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-03 15:33:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=62181.msg729444@s{hash}msg729444
@section 3 {tx}

  @s{quotedtext}

  @p{««} I used my Phone-a-Friend and Ask the Audience, and I'm locking in
  BIP 16 as my @p{(link}Final Answer@p{link)} (follow the link if you
  don't get the stale pop culture reference).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1473}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-05 16:30:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=23768.msg732395@s{hash}msg732395
@section 3 {tx}

  @s{quotedtext}

  @p{««} But what if somebody hacked into your server and modified the code
  that decides which addresses get paid out? @p{»»}

  @p{««}If they were smart, they'd shave just a little bit from everybody's
  payout and insert a payout to themselves... I imagine it could take
  quite a while before anybody noticed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1474}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-09 01:35:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63165.msg738756@s{hash}msg738756
@section 3 {tx}

  @p{««}Re-posted from the bitcoin-development mailing list: @p{»»}

  @p{««} I'd like version 0.6 to get lots of review, "soak time" and
  testing, so @p{brk} please download and run release candidate 1 from:
  @p{brk} @s{(link)} @p{»»}

  @p{««}You can review the code changes using github's compare feature:
   @p{brk} @s{(link)} @p{»»}

  @p{««}Please report bugs using the github issue tracker. @p{»»}

  @p{««} Release notes: @p{»»}

  @p{««}NEW FEATURES SINCE BITCOIN VERSION 0.5 p{»»}
  
  @p{««} Bitcoin-Qt can display and save QR codes for sending @p{brk} and
  receiving addresses. @p{»»}

  @p{««}New context menu on addresses to copy/edit/delete them. @p{»»}

  @p{««}New Sign Message dialog that allows you to prove that you @p{brk}
  own a bitcoin address by creating a digital @p{brk} signature. @p{»»}

  @p{««}Wallets created with this version of bitcoin will @p{brk} use
  33-byte 'compressed' public keys instead of @p{brk} 65-byte public keys,
  resulting in smaller @p{brk} transactions and less traffic on the
  bitcoin @p{brk} network. The shorter keys are completely @p{brk}
  compatible with older versions. @p{»»}

  @p{««}New command-line argument -blocknotify=@p{lt}command@s{gt} @p{brk}
  that will spawn a shell process to run @p{lt}command@s{gt} @p{brk} when
  a new block is accepted. @p{»»}

  @p{««}validateaddress JSON-RPC api command output includes @p{brk} two
  new fields for addresses in the wallet: @p{brk} pubkey : hexadecimal
  public key @p{brk} iscompressed : true if pubkey is a short 33-byte key
  @p{»»}

  @p{««}New JSON-RPC api commands for dumping/importing @p{brk} private
  keys from the wallet (dumprivkey, importprivkey). @p{»»}

  @p{««}New JSON-RPC api command for getting information about @p{brk}
  blocks (getblock, getblockhash). @p{»»}

  @p{««}New JSON-RPC api command for getting extra information @p{brk}
  related to mining (getmininginfo). @p{»»}

  @p{««} NOTABLE CHANGES  @p{»»}

  @p{««}The -nolisten, -noupnp and -nodnsseed command-line @p{brk} options
  were renamed to -listen, -upnp and -dnsseed, @p{brk} with a default
  value of 1. The old names are still @p{brk} supported for compatibility
  (so specifying -nolisten @p{brk} is automatically interpreted as
  -listen=0; every @p{brk} boolean argument can now be specified as either
  @p{brk} -foo or -nofoo). @p{»»}

  @p{««}The -noirc command-line options was renamed to @p{brk} -irc, with a
  default value of 0. Run -irc=1 to @p{brk} get the old behavior. @p{»»}

  @p{««} PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS @p{»»}

  @p{««}This release has preliminary support for multisignature @p{brk}
  transactions@p{--} transactions that require authorization @p{brk} from
  more than one person or device before they @p{brk} will be accepted by
  the bitcoin network. @p{»»}

  @p{««}Prior to this release, multisignature transactions @p{brk} were
  considered 'non-standard' and were ignored; @p{brk} with this release
  multisignature transactions are @p{brk} considered standard and will
  start to be relayed @p{brk} and accepted into blocks. @p{»»}

  @p{««}It is expected that future releases of Bitcoin-Qt @p{brk} will
  support the creation of multisignature transactions, @p{brk} once enough
  of the network has upgraded so relaying @p{brk} and validating them is
  robust. @p{»»}

  @p{««}For this release, creation and testing of multisignature @p{brk}
  transactions is limited to the bitcoin test network using @p{brk} the
  "addmultisigaddress" JSON-RPC api call. @p{»»}

  @p{««}Short multisignature address support is included in this @p{brk}
  release, as specified in BIP 16. Run with -bip16=0 to @p{brk} turn off
  support for BIP 16. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1475}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-09 14:46:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63165.msg739615@s{hash}msg739615
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, thanks for reminding me: I just uploaded gitian signatures for
  the win32 and linux 0.6rc1 builds to: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The win32 build was not deterministic, though. There's a pull
  request to fix that. @p{»»}

  @p{««}The OSX binary is not gitian-built. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1476}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-09 19:04:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63165.msg740034@s{hash}msg740034
@section 3 {tx}

  @s{quotedtext}

  @p{««} You are the Quality Assurance department. A test plan is an
  excellent idea, could you write one up and post it on the wiki and ask
  for volunteers to help test? @p{»»}

  @s{quotedtext}

  @p{««} I don't know, the GUI for multisignature transactions hasn't been
  designed yet. But I imagine it will be simpler to always produce P2SH
  transactions, just as the client always produces OP_HASH160 transactions
  and has no option to produce plain OP_CHECKSIG transactions. @p{»»}

  @p{««}I assume that both forms will be supported for multisig payments
  into your wallet (but detailed discussion on how to support multisig in
  the GUI should happen somewhere other than this thread). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1477}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-10 02:27:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63308.msg740715@s{hash}msg740715
@section 3 {tx}

  @p{««}Don't panic. @p{»»}

  @p{««}roconnor has been experimenting with spending "duplicate coinbase
  transactions" on the testnet. Block explorer is confused, and isn't
  seeing the 50 bitcoins generated to that address in testnet block 45,442
  (because the generation transaction has the same ID as the generation
  transaction in block 45,333). @p{»»}

  @p{««}Expect code changes before the 0.6 release is final to discourage
  and eventually prohibit accepting blocks with duplicate coinbase
  transactions; although we can't see a way to exploit this weirdness to
  cheat anybody (it is easy to cheat yourself out of bitcoins using
  duplicate coinbase transactions that cannot be spent), it's definitely
  not a good thing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1478}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-10 14:52:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=23768.msg741425@s{hash}msg741425
@section 3 {tx}

  @p{««}I hope they find and prosecute the bastards; DDoSing somebody
  because you disagree with them is never OK. @p{»»}

  @p{««}In fact, I think there is never a situation where DDoSing is OK,
  even if you're trying to accomplish something good (philosophical
  discussions about ends justifying the means should move to
  off-topic...)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1479}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-11 00:57:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63177.msg742334@s{hash}msg742334
@section 3 {tx}

  @s{quotedtext}

  @p{««} If you've got a great business model and funding for a much better
  bitcoin client, more power to you! @p{»»}

  @p{««}If you're planning on defacing one of the web servers that I
  haven't been keeping up-to-date (because I'm busy doing Bitcoin-related
  things) or hacking my gmail account to prove that I'm not The World's
  Best Security Expert... then I'll save you the trouble: @p{»»}

  @p{««}I am not the World's Best Security Expert. @p{brk} I am not the
  World's Best Programmer. @p{brk} I am not a cryptographer. @p{brk} I am
  not an expert on finance or banking or monetary systems. @p{brk} I am
  not an expert on leading open source projects. @p{»»}

  @p{««}And I hope someday I get replaced as the technical lead for this
  project. I'm sure there are lots of people better qualified than me, I'm
  just doing the best I can to try to help make Bitcoin a success. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1480}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-14 00:46:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63749.msg747108@s{hash}msg747108
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've got about $12 USD in my TradeHill account: Jered, please keep
  it, you deserve it, I know how hard you've worked and how hard a fight
  it is to interface with our
  designed-in-the-1960's-duct-tape-and-bailing-wire
  rats-nest-of-regulations banking/finance system. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1481}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-14 02:49:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56376.msg747338@s{hash}msg747338
@section 3 {tx}

  @p{««}Tomorrow at 21:00 UTC on @s{hash}bitcoin-dev I'd like to talk about: @p{»»}

  @p{««}Status of BIP 16 support (progress towards 50% hashing power).
  @p{»»}

  @p{««}Protocol change: checksum in version messages coming up Feb. 20.
  @p{»»}

  @p{««}Duplicate coinbase issue (and requiring block height in the
  coinbase as a solution). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1482}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-15 20:42:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63991.msg750792@s{hash}msg750792
@section 3 {tx}

  @p{««}This doesn't affect Bitcoin at all, because the ECDSA algorithm
  that Bitcoin uses does not use pairs of prime numbers to do it's thing.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1483}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-15 21:06:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=56376.msg750830@s{hash}msg750830
@section 3 {tx}

  @p{««}Meeting summary posted to the bitcoin-development mailing list
  (@p{(link}link@p{link)}) @p{»»}

  @p{««}IRC logs @p{(link}here@p{link)}.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1484}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-15 21:16:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64022.msg750850@s{hash}msg750850
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've got a "noprivacy" branch of bitcoin that I use for the
  Faucet: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Instead of creating a new address for change, it uses one of the
  input's addresses. @p{»»}

  @p{««}It works nicely if your entire bitcoin balance is one "account",
  but will fail if you're using the accounts feature to keep track of
  separate balances (which is why it will probably never be a mainline
  feature). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1485}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-21 22:30:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64279.msg761820@s{hash}msg761820
@section 3 {tx}

  @s{quotedtext}

  @p{««} I really like your idea of scaling up difficulty based on the
  number of domain operations in a block to prevent the key:value database
  from growing arbitrarily big. @p{»»}

  @p{««}It seems to me that should be enough to make domain operation
  pricing correct; I don't see why there needs to be a block reward or
  fees, I assume the registrars will charge whatever they need to charge
  to make a profit, and I would strongly encourage you to avoid making the
  DNS system yet-another-currency. I'd like to use dollars or euros or
  bitcoins (preferably bitcoins) to pay for my domain names, please. @p{»»}

  @p{««}I imagine a system something like: @p{»»}

  @p{(li}  I give some money to a registrar, and ask them to
  register/renew/transfer 'gavinandresen.dianna'  @p{li)}

  @p{(li}  The registrar makes sure the register/renew/transfer operation is
  valid  @p{li)}

  @p{(li}  The registrar bundles up a bunch of register/renew/transfer
  operations and then asks/pays a Bitcoin miner to merge-mine that hash to
  securely timestamp those changes  @p{li)}

  @p{(li}  After they're timestamped, the registrar asks that all of those
  record changes be inserted into a shared distributed hash table,
  providing the DIANNA proof-of-work and the bitcoin block hash.  @p{li)}

  @p{(li}  The nodes maintaining the shared DHT make sure the records have
  the right DIANNA proof-of-work, that the bitcoin block is valid, and
  that the changes aren't over-ridden by a later bitcoin block, and then
  update the records.  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1486}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-22 17:34:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64279.msg763130@s{hash}msg763130
@section 3 {tx}

  @s{quotedtext}

  @p{««} I should have made it clear: I imagine there will be an arbitrary
  number of registrars. They will compete to provide the best service
  (fastest updates of the DNS database, lowest prices, etc). @p{»»}

  @p{««}If you were willing to do the proof-of-work and insert your own
  updates into the bitcoin block chain then you could be your own
  registrar (I assume most people won't be willing to setup the necessary
  software, run it, etc. just to register a couple of domain names). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1487}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-22 20:03:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64279.msg763319@s{hash}msg763319
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes @p{»»}

  @s{quotedtext}

  @p{««}Yes, you could do it that way, re-using Bitcoin's Script system for
  signatures. I suppose it might be useful to require m-of-n signatures
  for a domain to be transferred to somebody else. I wouldn't make them
  full-fledged Transactions, though (multiple "inputs" to a domain renewal
  or transfer doesn't really make sense, for example). @p{»»}

  @s{quotedtext}

  @p{««} Yes, I think that's right, although I was imagining that the
  DIANNA and bitcoin difficulties would be kept separate and not combined.
  Combining them is probably a better idea (if you find any blocks that
  satisfy the bitcoin difficulty but not the DIANNA+bitcoin difficulty you
  can still announce them on the bitcoin network and get the block
  reward). @p{»»}

  @p{««}RE: what is the incentive for maintaining the DHT: the
  registrars/mining pools would, I think, be the primary maintainers of
  the DHT and their incentive to maintaining it is the registration fees
  that they charge. @p{»»}

  @p{««}I haven't thought deeply about possible attacks; if a DHT is used
  then you have to defend against Sybil attacks (you must have some way of
  checking to make sure the data you get from the DHT is valid, e.g. have
  the DHT nodes return a Merkle branch down to the data they're returning
  that you can verify hashes to the correct Merkle root). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1488}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-25 16:27:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64279.msg768297@s{hash}msg768297
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you might be conflating two costs: @p{»»}

  @p{««}Cost @s{hash}1 is the cost to get a bunch of domain transactions accepted.
  @p{»»}

  @p{««}I believe pent's proposal is based on additional difficulty, which
  will be independent of the bitcoin price. @p{»»}

  @p{««}In other words, if bitcoin difficulty is 100, then maybe you need
  to solve a difficulty 110 block to get your additional DIANNA data
  accepted by the other DIANNA nodes who are maintaining the key:value
  database. @p{»»}

  @p{««}If bitcoin difficulty rises to 1 million, then you need to solve a
  difficulty 1-million-and-ten block to get your data accepted. @p{»»}

  @p{««}The additional difficulty factor should be set by the DIANNA nodes
  based on their ability to process/store data. More thinking is needed
  about what that function looks like (it reminds me of the bitcoin fee
  algorithm; it's trying to solve a similar problem, preventing spam/abuse
  but allowing as many transactions as possible for the lowest possible
  price). @p{»»}

  @p{««}Then there's a completely separate Cost @s{hash}2, which will be higher
  than cost @s{hash}1, that is the payment that miners (aka registrars) will
  charge to handle domain transactions (and do the work of bundling them
  up, creating some sort of summary hash, and getting that hash into the
  bitcoin block chain). That's just a free market. @p{»»}

  @p{««} (I'm completely ignoring Cost @s{hash}3, which is the "what if I want to
  purchase an existing domain" price, and is whatever the owner is willing
  to sell it for.) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1489}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-27 03:20:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=58579.msg771030@s{hash}msg771030
@section 3 {tx}

  @s{quotedtext}

  @p{««}In my humble opinion, this kind of trash talk against BIP 16 is bad
  for Bitcoin. @p{»»}

  @p{««}The poll in this thread says the community prefers BIP 16. @p{»»}

  @p{««}The @p{(link}chart on the bitcoin wiki@p{link)} says the core
  developers prefer BIP 16. @p{»»}

  @p{««}And the @p{(link}actions of the big mining pools and independent
  miners@p{link)} says that they overwhelmingly prefer BIP 16. @p{»»}

  @p{««}Luke, I'd be delighted to add Eligius to the list of pools that are
  supporting BIP 16 in my signature.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1490}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-27 16:19:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66514.msg771881@s{hash}msg771881
@section 3 {tx}

  @p{««}Reposting from the bitcoin-development mailing list: @p{»»}

  @p{««}@p{hrule} @p{brk} Mining support for BIP 16 is still under 50%, and
   won't possibly be over 50% by March 1. Which means we need a new
   evaluation/switchover date: @p{»»}

  @p{««}Re-evaluate support: March 15'th @p{brk} Target switchover: April 1
  @p{»»}

  @p{««}If you're already supporting BIP16, restart bitcoind with the
  argument: @p{»»}

    @p{(li}-paytoscripthashtime=1333238400 @p{li)}

  @p{««}... to delay switchover until April 1. @p{»»}

  @p{««}Hopefully this will be the last delay; Tycho has told me that the
  deepbit pool will support BIP16 as soon as he's able to merge and test
  the changes, which will put support at well over 55%. @p{»»}

  @p{««} @p{hrule} If you are a solo or p2pool miner you are
  @p{(bf}strongly@p{bf)} encouraged to upgrade bitcoind/Bitcoin-Qt in the
  next month; if you don't, you risk creating orphan blocks that the rest
  of the network will reject (and that risk will rapidly become greater
  over time as BIP16 transactions start to appear in the main block chain
  and get relayed across the network). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1491}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-28 16:11:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66514.msg773732@s{hash}msg773732
@section 3 {tx}

  @p{««}eleuthria is right. @p{»»}

  @p{««}The bad-for-not-upgraded-miners scenario is: @p{»»}

  @p{(li}  Somebody gets a valid BIP16 transaction into the chain.  @p{li)}

  @p{(li}  They then spend that transaction by broadcasting a 'standard',
  non-BIP16 transaction, BUT they create a signature for the BIP16 part
  that old miners consider valid, new miners consider invalid.  @p{li)}

  @p{(li}  The old miners will add that 'poisonous' transaction to their
  memory pool and if they include it in the blocks they mine then those
  blocks will be rejected by most of the network.  @p{li)}

  @p{««}makomk pointed out a while ago that I hadn't noticed that old
  miners will accept spends of half-valid BIP16 transactions, because the
  old code doesn't check to see if a transaction is @p{(it}spending@p{it)}
  a non-standard input. He's right; one of the changes in the 0.6 release
  is an AreInputsStandard() method, to make upgrading smoother next time.
  @p{»»}

  @p{««}Executive summary: if you are a p2pool or solo miner you should
  upgrade before the switchover date (April 1, if all goes well) or there
  is a good chance you'll produce nothing but orphan blocks. I welcome
  suggestions on how to effectively get that message out to the community.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1492}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-28 16:15:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66537.msg773735@s{hash}msg773735
@section 3 {tx}

  @s{quotedtext}

  @p{««} @s{(link)} @p{»»}

  @p{««}... but it is pretty narrowly targeted at stress-testing the
  transaction validity code. @p{»»}

  @p{««}Last year at the NYC conference I mentioned that I would really
  like to see somebody who knows a lot more about network simulation than
  I do develop tools to help test proposed protocol changes, simulate
  Sybil or DoS attacks, etc. @p{»»}

  @p{««}I'd still really like to see that...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1493}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-28 23:38:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66548.msg774383@s{hash}msg774383
@section 3 {tx}

  @s{quotedtext}

  @p{««} Do you @p{(it}have@p{it)} to talk about those three projects?
  @p{»»}

  @p{««}How about Bitcoin-Charity.com or CoinWorker.com for projects that
  aren't so potentially controversial?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1494}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-02-29 00:40:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=64777.msg774467@s{hash}msg774467
@section 3 {tx}

  @p{««}This would replace the existing JSON-RPC getmemorypool command?
  @p{»»}

   @s{code}

  @p{««} If (data) is not specified, returns data needed to construct a
  block to work on: @p{»»}

    @p{(li}"version" : block version @p{li)}

    @p{(li}"previousblockhash" : hash of current highest block @p{li)}

    @p{(li}"transactions" : contents of non-coinbase transactions that
    should be included in the next block @p{li)}

    @p{(li}"coinbasevalue" : maximum allowable input to coinbase
    transaction, including the generation award and transaction fees
    @p{li)}

    @p{(li}"coinbaseflags" : data that should be included in coinbase so
    support for new features can be judged @p{li)}

    @p{(li}"time" : timestamp appropriate for next block @p{li)}

    @p{(li}"mintime" : minimum timestamp appropriate for next block
    @p{li)}

    @p{(li}"curtime" : current timestamp @p{li)}

    @p{(li}"bits" : compressed target of next block @p{li)} If (data) is
  specified, tries to solve the block and returns true if it was
  successful. @p{»»}

  @p{««} And a meta-question: are there any other implementations that will
  be supporting external mining via JSON-RPC soon? There's no reason to go
  through the whole BIP process to make a change or improvement to one
  implementation. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1495}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-01 13:36:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55184.msg776962@s{hash}msg776962
@section 3 {tx}

  @p{««}From the arimaa whitepaper: @p{»»}

  @s{quotedtext}

  @p{««}Right@p{--} good luck with that! Any system that relies on Wise,
  Efficient and Effective Bureaucracies to decide hard questions like "are
  these 400 accounts really one scammer trying to get more than their fair
  share" are doomed to fail if they ever get large enough to attract the
  attention of scammers. @p{»»}

  @p{««}If you have a really good automated way of telling the scammers
  from real people that doesn't require them sending in a DNA sample or
  body part, please let me know. I could use a good solution for the
  Bitcoin Faucet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1496}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-01 17:00:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66887.msg777279@s{hash}msg777279
@section 3 {tx}

  @p{««}Windows, Linux and Mac binaries for 0.6rc2 are up at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please use github to report bugs: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Note that there were a few "release candidate 1 doesn't work on
  Windows" bug reports that, as far as I know, have not been fixed. We
  need some good Qt-on-Windows developers to help out, none of the current
  core developers use Windows as our primary development platform. @p{»»}

  @p{««}A lot of bug-fixing happened between release candidate 1 and
  release candidate 2, but we did also sneak in one major new feature that
  was long overdue: a Backup Wallet menu entry. @p{»»}

  @p{««}@p{(bf}Be aware:@p{bf)} the 0.6 release will create wallet.dat
  files that will not work with older releases, so you should back-up your
  wallet before running in case you need to revert back to an older
  release. 0.6 doesn't mark the wallet as backwards-incompatible until a
  new 'compressed' keypool key is added, so until you do something that
  generates a new key the wallet will stay compatible. Compressed keys
  will benefit everybody by using less network bandwidth, allowing more
  transactions to fit into each block, and making the blockchain smaller
  than it would otherwise be. @p{»»}

  @p{««}Even a little time testing helps a lot; if you do can do some
  testing please reply in this thread with a message like "Bitcoin-Qt and
  bitcoind both worked nicely for me on my OS 10.6.8 Mac, running on
  -testnet." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1497}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-01 20:00:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66916.msg777630@s{hash}msg777630
@section 3 {tx}

  @p{««}FYI: @p{»»}

  @p{««}The Bitcoin Faucet bitcoind's are both running on a Linode VPS,
  which was mysteriously restarted 14 hours ago. The 5 bitcoins in the
  main-net Faucet's wallet were stolen, also; I'll shutdown the Faucet
  website, do NOT donate any coins to the Faucet donation address, it is
  controlled by the thief. @p{»»}

  @p{««}Transaction ID:
  14350f6f2bda8f4220f5b5e11022ab126a4b178e5c4fca38c6e0deb242c40c5f @p{brk}
  ... if you want to start watching where the coins end up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1498}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-01 21:46:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66887.msg777872@s{hash}msg777872
@section 3 {tx}

  @s{quotedtext}

  @p{««}The dreaded DB_RUNRECOVERY... that's usually caused by running an
  older version of BDB (0.6 is compiled against BDB 4.8) on a datadir
  written with a newer version of BDB. @p{»»}

  @p{««}Recovery isn't hard; just delete the .bitcoin/database/log.000*
  file(s) and any .bitcoin/__db*.log files. Were you previously running a
  self-compiled version of Bitcoin? @p{»»}

  @p{««}From @p{(link}@s{(link)}@s{hash}divining-bdb-version@p{link)} : @p{»»}

  @p{««}Code: cd ~/.bitcoin/database @p{brk} od -j12 -N8 -tx4 log.000*
  @p{brk} ... will show what version of BDB the log files were written
  with.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1499}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-02 18:30:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63165.msg780022@s{hash}msg780022
@section 3 {tx}

  @s{quotedtext}

  @p{««}Nice! Thank you very much for looking deeply into this; it looks
  like the inter-process-communication doo-hickey bitcoin uses to handle
  bitcoin: URLs was left behind when you blue-screened, and that's making
  startup fail the next time around.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1500}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-03 17:24:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67105.msg781681@s{hash}msg781681
@section 3 {tx}

  @p{««}If you're using multisig to secure your wallet, then I think backup
  could be "free" ; all the involved multisig keys could be derived
  predictably from singlesig keys that you'll already need to backup.
  Disaster recovery from a lost wallet would mean importing all the backed
  up singlesig keys, then deriving (say) the first 1000 multisig
  ScriptSigs that would have been derived from those keys and scanning the
  blockchain for transactions involving those (and, hand-wave, hand-wave,
  doing something smart to derive more than 1000 in case it looks like
  more than 1000 were used). (or, in other words: what kjj said) @p{»»}

  @p{««}If you're using multisig for escrow involving other people... then
  the escrow transaction has to be recorded and backed up, including all
  the keys involved. In that case I'm pretty sure you'll want to record
  and backup other information about the escrow@p{--} like "100 BTC escrow
  to my cousin Bob; release them if he's still not smoking on June 1."
  @p{»»}

  @p{««}Backup should be part of the user experience design for the escrow
  function; for example, I think a lot of escrows will an associated date,
  so the client should store the escrow transaction id AND the public keys
  involved in the escrow AND a "remind me to do something on June 1" AND
  (maybe) a link to my Address Book entry for Bob so I can call him on
  June 1. For me, I think the best way to backup that kind of escrow
  information would be for the client to send me an email containing all
  of that stuff in a standardized mini-file-format; I'll let gmail archive
  it and that would be my emergency backup. @p{»»}

  @p{««}So, emergency recovery of a lost wallet would then be: @p{»»}

    @p{(li} 1. Recover all private keys from paper backup (or whatever the
  singlesig backup solution is). @p{brk} 2. Re-import all escrows that
  involve other people from email archive. @p{li)}

  @p{««} RE: Bytecoin and "OR BACKUP_KEY" : In either the OP_EVAL or the
  BIP16 case you need a new type of 'standard' transaction (and bitcoin
  address) to make that work.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1501}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-03 18:38:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67158.msg781736@s{hash}msg781736
@section 3 {tx}

  @p{««}Those 0.002 bitcoins cannot be redeemed, because there is no input
  that will make that script valid (because there are no OP_ENDIF opcodes
  in there to match the OP_IFDUP/OP_IF opcodes). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1502}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-04 18:06:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66521.msg783136@s{hash}msg783136
@section 3 {tx}

  @p{««}RE: tx replacement: @p{»»}

  @p{««}Somebody aught to start experimenting with transaction replacement
  with testnet-in-a-box. @p{»»}

  @p{««}Put together a test plan, modify the code and try to break it.
  @p{»»}

  @p{««}Assuming it all works, submit a pull request to enable transaction
  replacement on testnet (with a pointer to your test plan and results of
  testing, please). @p{»»}

  @p{««}Then we can start trying to break transaction replacement on
  testnet; again, assuming no bugs/hacks/issues turn up after "enough"
  testing, and if there's general consensus that the benefits outweigh the
  risks, it could be rolled out to the production network. @p{»»}

  @p{««}We just pulled a DoS fix involving filling up memory with orphan
  transactions; one concern with transaction replacement is DoS (could I
  fill up the memory pool by spamming "will be replaced"
  transactions?)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1503}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-06 00:24:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67508.msg785384@s{hash}msg785384
@section 3 {tx}

  @p{««}Great ideas, Mike. I think the "use two servers" approach will
  happen first (you typically want at least two servers anyway just for
  backup and redundancy), but trusted code running in a TPM could be an
  extremely powerful and cost-effective building block for much more
  secure solutions. @p{»»}

  @p{««}RE: @p{»»}

  @s{quotedtext}

  @p{««} That seems like the hardest problem. @p{»»}

  @p{««}Does the TPM have access to a guaranteed-to-be-unhackable time
  source? If it does, then a policy like "do not approve more than X
  bitcoins worth of transactions in timeperiod Y" should work well enough
  to prevent more than petty theft, assuming you've got some other way of
  watching the blockchain for unauthorized transactions and shutting down
  the compromised machine or using an emergency offline backup key to move
  the funds to a non-compromised wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1504}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-06 13:34:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67508.msg786207@s{hash}msg786207
@section 3 {tx}

  @s{quotedtext}

  @p{««} I was thinking of a kind of replay attack: @p{»»}

  @p{(li}  Control the TPM's view of the world (e.g. make it seem like it is
  Jan 1, 2010)  @p{li)}

    @p{(li}@p{(li} Get the TPM to sign a small transaction, shut it down.
    @p{li)} @p{(li} Increment time, get it to sign another transaction
    @p{li)} @p{(li} Repeat. @p{li)}

  @p{««}Replace "time" with "blockchain" and you've got the same problem:
  can the TPM know that it's view of the external world is correct? If it
  sends a nonce (to prevent replay attacks) to some external service that
  adds a timestamp and signs it with a public key known to the TPM code...
  then we're back to using two different servers. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1505}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-06 16:02:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67515.msg786442@s{hash}msg786442
@section 3 {tx}

  @s{quotedtext}

  @p{««}That is always a risk, which is why next to the downloads there is
  a gpg-signed SHASUMS.asc file. @p{»»}

  @p{««}To check the integrity of the download you should: @p{»»}

  @p{(li}  Check the signature on the SHASUMS.asc file:  @p{li)}

  @p{««}Code: $ gpg @p{--}verify SHASUMS.asc @p{brk} gpg: Signature made
  Wed Feb 29 20:51:40 2012 EST using RSA key ID 1FC730C1 @p{brk} gpg: Good
  signature from "Gavin Andresen (CODE SIGNING KEY)
  @p{lt}gavinandresen@s{at}gmail.com@s{gt}" @p{(li} Make sure the checksum for
  the downloaded file matches the checksum in the SHASUMS.asc file:
  @p{li)}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1506}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-06 16:35:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66714.msg786501@s{hash}msg786501
@section 3 {tx}

  @p{««}You should be able to build your GL on top of the accounts feature
  of bitcoind. @p{»»}

  @p{««}The 'validateaddress' RPC call will tell you the account associated
  with an address and whether or not it is an address that belongs to you
  or is external. @p{»»}

  @p{««}Combined with the 'sendfrom' and 'setaccount' RPC calls, you should
  be able to create a proper general-ledger-type application where all
  transactions have well-defined "from" and "to" accounts. @p{»»}

  @p{««}Example of one way to do it using my testnet-in-a-box setup: @p{»»}

    @p{(li} 1. Create a couple of accounts: @p{li)}

  @p{««}Code: ./bitcoind -testnet getaccountaddress "cash" @p{brk} @s{hash} ...
   send some coin to the "cash" account from ... somewhere ... @p{brk}
   ./bitcoind -testnet setaccount mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ
   "hosting_expenses" @p{brk} @s{hash} the mzDfb... address would come from my
   web hosting company, of course @p{»»}

  @p{««} 2. Now pay for web hosting out of "cash" @p{»»}

  @s{code}

  @p{««} 3. All the information about the transaction (from and to
  accounts) is available, but you'll need 2 RPC calls to get it: @p{»»}

  @s{code}

  @p{««} The GUI has no notion of a "sendfrom account", so any coins send
  from the GUI won't play nicely with whatever system you create using the
  RPC interface. The expectation is the vast majority of GUI users won't
  go to the trouble of creating a general ledger system to keep track of
  where their bitcoins are coming from and going to. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1507}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-06 16:39:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66714.msg786509@s{hash}msg786509
@section 3 {tx}

  @p{««}PS: The 'accounts' feature doesn't scale well past a dozen or two
  accounts each with a few hundred transactions. It could (need to add
  some indices to the database so looking up transactions by account
  and/or time is quick), but doing that work hasn't been a high
  development priority. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1508}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-10 01:43:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68091.msg793328@s{hash}msg793328
@section 3 {tx}

  @p{««}Bitcoin doesn't install Growl@p{--} something else must have in the
  past. @p{»»}

  @p{««}PS: there is an open bug in the 0.6 release that it is not
  compatible with some versions of Growl; if that isn't resolved Growl
  notifications might be completely disabled.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1509}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-10 01:44:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=66887.msg793332@s{hash}msg793332
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, fixed in rc2.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1510}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-10 15:13:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68128.msg794061@s{hash}msg794061
@section 3 {tx}

  @p{««}There have already been several "transaction spam" attacks; as
  already pointed out, transaction fees keep them from being a big
  problem. @p{»»}

  @p{««}The code also limits the number of free transactions that are
  relayed across the network, so you can't flood the network with
  transactions that will never get mined. @p{»»}

  @p{««}Smarter denial-of-service attack prevention code has been a major
  unseen feature of the last couple Bitcoin releases. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1511}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-10 15:31:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68133.msg794081@s{hash}msg794081
@section 3 {tx}

  @p{««}Stay tuned: the testnet is a mess right now. Another genesis block
  reset might be needed to fix it, there have been several
  blockchain-splitting changes and there are several different versions of
  the blockchain competing (with/without the difficulty change,
  with/without the duplicate coinbase change, and with/without BIP16
  support). @p{»»}

  @p{««}In the meantime, testing with a testnet-in-a-box or private testnet
  is a good way to go: @p{»»}

    @p{(li}@s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1512}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-10 20:37:13 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68133.msg794440@s{hash}msg794440
@section 3 {tx}

  @p{««}Testnet is healthier now, although you'll need to run latest 'git
  HEAD' to be on the right chain. Thanks to everybody who threw some
  hashing power at it to outrun the bad, old-rules chains. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1513}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-13 16:12:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68627.msg799401@s{hash}msg799401
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}... has a fairly recent copy of the blockchain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1514}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-14 12:19:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68677.msg801026@s{hash}msg801026
@section 3 {tx}

  @s{quotedtext}

  @p{««} I agree. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1515}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-17 00:17:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69120.msg805883@s{hash}msg805883
@section 3 {tx}

  @p{««}A potential security vulnerability has been discovered in the
  Windows @p{brk} version of Bitcoin-Qt. If you are running Bitcoin-Qt
  versions 0.5 @p{brk} through 0.6 on Windows you should shut it down and
  upgrade to either @p{brk} version 0.5.3.1 or 0.6rc4 NOW. @p{»»}

  @p{««}The command-line bitcoin daemon (bitcoind), Mac and Linux versions
  of @p{brk} Bitcoin-Qt, and versions prior to 0.5 are not affected. @p{»»}

  @p{««}Due to the nature of the vulnerability, we believe it would be very
  @p{brk} difficult for an attacker to do anything more than crash the
  @p{brk} Bitcoin-Qt process. However, because there is a possibility of
  such a @p{brk} crash causing remote code execution we consider this a
  critical issue. @p{»»}

  @p{««}Binaries are available at SourceForge: @p{brk} @s{(link)} @p{brk}
  @s{(link)} @p{»»}

  @p{««}If you have questions, feel free to drop by the @s{hash}bitcoin-dev
  channel @p{brk} on FreeNode IRC. @p{»»}

  @p{««}- @p{--} @p{brk} Gavin Andresen @p{brk} Gregory Maxwell @p{brk}
  Matt Corallo @p{brk} Nils Schneider @p{brk} Wladimir J. van der Laan @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1516}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-18 13:44:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69120.msg807754@s{hash}msg807754
@section 3 {tx}

  @s{quotedtext}

  @p{««}We'll release full detail tomorrow (Monday) at 16:00 GMT, after
  essentially the entire world has had a chance to go into work Monday
  morning, see the alert message, and shutdown/upgrade.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1517}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-18 14:00:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67105.msg807766@s{hash}msg807766
@section 3 {tx}

  @s{quotedtext}

  @p{««} How are signatures created when the phone or computer needs to
  spend some coins? @p{»»}

  @p{««}I'm told it IS possible to break a single ECDSA key in half and
  then have a complete signature generated without either device ever
  knowing the entire key, but, if I recall correctly, the solution
  involves several communication round trips between the devices and some
  very sophisticated cryptography. The multikey solution is much simpler.
  @p{»»}

  @p{««}If I'm wrong, then great! The single ECDSA key solution will get
  adopted for wallet security and multisigs will only be used for escrow.
  @p{»»}

  @p{««}RE: makku's question "How do you identify transactions that belong
  to you in the first place?" @p{»»}

  @p{««}I think it is wrong to think of coins involved in a multiparty
  multisignature transaction as "belonging to you." They don't belong to
  you@p{--} you have to agree and cooperate with other keyholder(s) for
  the transaction to be spent. @p{»»}

  @p{««}You are @p{(it}involved@p{it)} in the transaction, but you need
  some extra information that isn't in the blockchain to know how you are
  involved (are you an arbitrator? a person getting paid? a person paying
  somebody? something else?). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1518}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-18 16:12:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=55600.msg807871@s{hash}msg807871
@section 3 {tx}

  @p{««}I started experimenting with user-defined checkpoints
  (-checkpoint=height,hash multiarg, and 'addcheckpoint @p{lt}height@s{gt}
  @p{lt}hash@s{gt}' RPC call) but stopped when higher priority issues came
  up. @p{»»}

  @p{««}It seems to me that type of low-level mechanism is the right way to
  go; checkpointing is a good low-level way of identifying which chain you
  think is "the" chain. And making it command-line/RPC configurable means
  we don't all have to agree on One True Way of deciding what the right
  blockchain aught to be; cunicula can write some code that implements
  proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.
  etotheipi can write some code that scans the blockchain for well-known
  miner signatures (or asks miners directly if they produced a new block),
  etc. @p{»»}

  @p{««}If your argument is "But Gavin, if core Bitcoin doesn't support One
  True Way of doing I'll never be able to convince miners to do it my
  way!" then I'd say you need to better express to them how the benefits
  of your proposal outweigh the costs.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1519}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-18 17:14:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69230.msg807933@s{hash}msg807933
@section 3 {tx}

  @s{quotedtext}

  @p{««} Check your math@p{--} to get 51% you'll need to dedicate six times
  as much hardware to hashing as it takes to get 15%: @p{»»}

  @p{««}The formula for what fraction of existing hashing power you need
  add to get X% of the network is: @p{»»}

  @p{««}Code: H = X / (1-X) @p{brk} To get 15%, you need to add 17.6%. E.g.
  if existing hashing power is 100, then you add 17.6 more and your
  fraction is (17.6/117.6) = 0.15. @p{»»}

  @p{««}To get 51%, you need to add 104%. E.g. if existing hashing power is
  100, then you add 104, then your fraction is (104/204) = 0.51. @p{»»}

  @p{««}104 is six times as much as 17.6. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1520}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-19 16:02:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69120.msg809255@s{hash}msg809255
@section 3 {tx}

  @p{««}Full disclosure blog post is at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Executive summary: we were compiling Windows binaries with the
  wrong flags. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1521}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-19 17:43:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69423.msg809437@s{hash}msg809437
@section 3 {tx}

  @p{««}Not relaying "smelly" blocks is a very interesting idea. @p{»»}

  @p{««}It doesn't have to be a binary relay/don't relay... you could
  immediately relay good blocks but wait a while before relaying bad
  blocks, and make the length of time you wait to relay based on how bad
  you think they are (maximum of maybe 10 minutes before you relay). @p{»»}

  @p{««}But... not relaying new blocks immediately might just encourage the
  bad guys to try to connect directly to as many nodes as possible, and
  that could be bad for network health. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1522}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-20 00:27:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69520.msg810136@s{hash}msg810136
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1523}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-20 12:56:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=70033.msg810958@s{hash}msg810958
@section 3 {tx}

  @s{quotedtext}

  @p{««}Great! Pull requests to fix compiling-on-platform-X problems are
  always welcome (assuming they don't also break compiling on platform-Y).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1524}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-21 16:17:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71226.msg812897@s{hash}msg812897
@section 3 {tx}

  @p{««}To all pool operators, solo miners and p2pool miners; I have an
  announcement. @p{»»}

  @p{««}As everyone well remembers, we are upgrading the block-validity
  rule of Bitcoin to support short multisignature addresses. We realize
  that upgrading the code that you've been using for a long time is at
  least inconvenient and, for some of you, even painful or scary. But in
  the case of BIP30, which went into effect with the appropriately safe
  network support on March 15, it was necessary and in the case of this
  announcement the long-term benefits will far outweigh the short-term
  costs of this transition. @p{»»}

  @p{««}Therefore I'd like to announce that support for BIP16 has acquired
  a majority of mining support needed to prevent a potential permanent
  fork and will be activated on April 1st as previously planned. @p{»»}

  @p{««}This chart shows support over the last week: @s{(link)}. Support is
  well over 70%. @p{»»}

  @p{««}So if you are a pool operator, solo miner, or p2pool miner you need
  to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version
  of bitcoind earlier than 0.6 release candidate 3 past this date means
  running the risk of potentially wasting your hashing power mining
  invalid blocks since earlier versions will accept invalid spends of
  BIP16 transactions into their memory pools and will put them into blocks
  considered invalid by the majority. @p{»»}

  @p{««}p2pool users will also need to upgrade to the latest version of
  p2pool. @p{»»}

  @p{««}If you are a miner connecting to a mining pool, you can ignore this
  message. @p{»»}

  @p{««}For non-miners: version 0.6 also contains several important bug and
  denial-of-service fixes, so if you can, upgrade. @p{»»}

  @p{««}Backports of the BIP16 code to earlier releases
  @p{(link}are@p{link)} @p{(link}available@p{link)} if you are running a
  patched bitcoind. Patched binaries of older releases will be available
  soon.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1525}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-21 16:29:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71282.msg812917@s{hash}msg812917
@section 3 {tx}

  @p{««}I'm posting this to both this and the Mining Pools subforum: @p{»»}

  @p{««}To all pool operators, solo miners and p2pool miners; I have an
  announcement. @p{»»}

  @p{««}As everyone well remembers, we are upgrading the block-validity
  rule of Bitcoin to support short multisignature addresses. We realize
  that upgrading the code that you've been using for a long time is at
  least inconvenient and, for some of you, even painful or scary. But in
  the case of BIP30, which went into effect with the appropriately safe
  network support on March 15, it was necessary and in the case of this
  announcement the long-term benefits will far outweigh the short-term
  costs of this transition. @p{»»}

  @p{««}Therefore I'd like to announce that support for BIP16 has acquired
  a majority of mining support needed to prevent a potential permanent
  fork and will be activated on April 1st as previously planned. @p{»»}

  @p{««}This chart shows support over the last week: @s{(link)}. Support is
  well over 70%. @p{»»}

  @p{««}So if you are a pool operator, solo miner, or p2pool miner you need
  to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version
  of bitcoind earlier than 0.6 release candidate 3 past this date means
  running the risk of potentially wasting your hashing power mining
  invalid blocks since earlier versions will accept invalid spends of
  BIP16 transactions into their memory pools and will put them into blocks
  considered invalid by the majority. @p{»»}

  @p{««}p2pool users will also need to upgrade to the latest version of
  p2pool. @p{»»}

  @p{««}If you are a miner connecting to a mining pool, you can ignore this
  message. @p{»»}

  @p{««}For non-miners: version 0.6 also contains several important bug and
  denial-of-service fixes, so if you can, upgrade. @p{»»}

  @p{««}Backports of the BIP16 code to earlier releases
  @p{(link}are@p{link)} @p{(link}available@p{link)} if you are running a
  patched bitcoind. Patched binaries of older releases will be available
  soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1526}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-22 14:54:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69337.msg814329@s{hash}msg814329
@section 3 {tx}

  @s{quotedtext}

  @p{««}I pulled @s{hash}964 for 0.6 this morning. @p{»»}

  @p{««}I had played with database settings several months ago and saw no
  speedup because there was another bug causing a bottleneck. That bug was
  fixed a while ago, but nobody thought to try tweaking the db settings
  again until a few days ago. @p{»»}

  @p{««}Pieter and Greg did all the hard work of doing a lot of
  benchmarking to figure out which settings actually matter. @p{»»}

  @p{««}PS: the database settings are run-time configurable for any version
  of bitcoin; berkeley db @p{(link}reads a file called
  'DB_CONFIG'@p{link)} (if it exists) in the "database environment"
  directory (aka -datadir). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1527}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-22 15:00:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71282.msg814341@s{hash}msg814341
@section 3 {tx}

  @p{««}See this thread for BIP16-compatible-backported release candidates:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}A final 0.6 release candidate will be out very soon, the last
  issues are being resolved now. @p{»»}

  @p{««}Again: if you don't upgrade and are a solo miner, pool operator, or
  p2pool user you will @p{(bf}almost certainly waste time hashing bad
  blocks@p{bf)} after April 1. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1528}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-22 17:23:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=68121.msg814573@s{hash}msg814573
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's source code for the kernel, right? @p{»»}

  @p{««}I removed the old binary releases from SourceForge because it was
  getting annoying to find things like testnet-in-a-box in that very long
  list, and also getting hard to see what the latest release was. And with
  our gitian reproducible build process, the windows/linux binaries for
  recent releases are deterministically reproducible from the source code.
  @p{»»}

  @p{««}See @s{(link)} for the history back to the 0.1.5 release. Uploading
  0.1 to github is a good idea, maybe somebody who knows more about git
  than I do can suggest the best way to do that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1529}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-23 13:30:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71282.msg815761@s{hash}msg815761
@section 3 {tx}

  @s{quotedtext}

  @p{««} That statement is incorrect. @p{»»}

  @p{««}There are two ways you might waste time hashing: @p{brk} 1) Put a
  bad BIP16 transaction in your block @p{brk} 2) Building on top of a bad
  block produced by somebody else @p{»»}

  @p{««}So even if you don't include anybody else's transactions in your
  blocks you will still almost certainly waste some time hashing by
  building on top of invalid blocks produced and announced by some other
  lazy miner running an old version of bitcoind.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1530}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-26 15:58:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74059.msg820345@s{hash}msg820345
@section 3 {tx}

  @p{««}Start with @p{(link}this stickied thread.@p{link)} 

# ----------------------------------------------------------------------
@section 2 {ms1531}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-26 23:43:02 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74214.msg821210@s{hash}msg821210
@section 3 {tx}

  @p{««}Barring any last-minute showstopper issues, the plan is for release
  candidate 5 to become the official 0.6.0 release on Wednesday. @p{»»}

  @p{««}So please help look for last-minute showstopper issues: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The major changes from release candidate 4: @p{»»}

  @p{««} @p{(li}Much faster writing of blkindex.dat during initial
  blockchain download (by modifying the default bdb environment cache
  settings)@p{li)}

    @p{(li}A new policy for wallet.dat upgrades: use the old format unless
    the user either uses a feature that requires an upgrade (encrypts the
    wallet) or explicitly requests that the wallet be upgraded using the
    new -upgradewallet option. New wallets will use new features (for 0.6,
    the only new wallet feature is compressed public keys).@p{li)}

    @p{(li}bugfix introduced in rc4 for an assertion failure that could
    occur during blockchain reorganizations@p{li)}

    @p{(li}New code for managing the addr.dat file that prevents an
  attacker from filling it with bogus entries. @p{li)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1532}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-26 23:58:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74122.msg821239@s{hash}msg821239
@section 3 {tx}

  @s{quotedtext}

  @p{««} Here's the thinking: @p{»»}

  @p{««}Joe Random User finds out about bitcoin, and decides "what the
  heck, I'll check it out." @p{»»}

  @p{««}They run it. First thing it does is ask him for a passphrase, with
  tons of "DO NOT FORGET YOUR PASSPHRASE" and/or "CHOOSE A LONG
  PASSPHRASE" warnings. What does he do? Many users will either: @p{»»}

    @p{(li} 1. Type "passphrase". @p{li)}

  @p{««}or @p{»»}

    @s{code}

  @p{««}He gets a little coin from the Faucet, writes me an email asking
  when they will arrive (because he hasn't yet downloaded the entire
  blockchain and didn't bother to read the information about that on the
  Faucet's "Sent!" page), and then shuts down the client. @p{»»}

  @p{««}Time passes. Eventually the Faucet coins show up. @p{»»}

  @p{««}He decides Bitcoin really doesn't suck as much as he first thought,
  so he decides to buy some Bitcoin on Mt. Gox. @p{»»}

  @p{««}Time passes while Dwolla verifies his bank account and stuff. @p{»»}

  @p{««}Then he buys Bitcoin, and manages to send them and see them show up
  in his running Bitcoin. @p{»»}

  @p{««}Yay! @p{»»}

  @p{««}Time passes. He decides he wants to spend the Bitcoin, and now he
  has to enter the passphrase that he set a week or three ago. But back
  then, wallet security wasn't at all important to him. He didn't have an
  Bitcoins to keep secure. @p{»»}

  @p{««}So either he forgot that his passphrase is "passphrase" or he
  remembers that he typed a bunch or random letters just so he could get
  past that annoying "enter passphrase" dialog box so he could just
  @p{(bf}try@p{bf)} the damn thing. @p{»»}

  @p{««}In short: wallet encryption is not the default because the right
  time to enter a passphrase to encrypt the wallet is when you KNOW that
  the wallet is valuable, and will take the steps necessary to protect it.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1533}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-27 00:38:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74122.msg821296@s{hash}msg821296
@section 3 {tx}

  @s{quotedtext}

  @p{««}Ummm... @p{»»}

  @p{««}You know when you choose "About Bitcoin-Qt" and it says "Version
  0.something BETA" ? @p{»»}

  @p{««}When we've got an implementation that is safe and secure (both from
  hackers and from accidental loss) out of the box that will change to say
  "Bitcoin Version 1.something". @p{»»}

  @p{««}Unfortunately, I don't know how to launch Bitcoin in an alternate
  universe where it will be attacked by highly motivated black-hats and
  then bring back the battle-tested source code to this universe to be
  launched as a perfectly secure Version One. @p{»»}

  @p{««}So, to repeat myself: Bitcoin is experimental software. Do not
  invest time or money in it that you cannot afford to lose. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1534}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-27 13:13:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74122.msg822170@s{hash}msg822170
@section 3 {tx}

  @s{quotedtext}

  @p{««}You mean like: @p{»»}

  @p{««}@s{(link)} @p{»»}

    @p{(li}or @p{li)} @s{(link)} @p{»»}

    @p{(li}or @p{li)} @s{(link)} @p{»»}

    @p{(li}or @p{li)} @s{(link)} @p{»»}

  @p{««}It has been a while since I wrote a "State of Bitcoin Development"
  update (too busy...), but wallet security was my second priority, behind
  network stability, the last time I did one. It is still right at the top
  of my priority list.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1535}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-28 16:55:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=63165.msg824410@s{hash}msg824410
@section 3 {tx}

  @s{quotedtext}

  @p{««} We might re-spin the release with just updated translations. @p{»»}

  @p{««}There is one serious issue affecting a few people (@s{(link)}) but
  because it is a one-time problem when you upgrade from an older release
  and has a pretty simple workaround (remove your addr.dat file and
  re-run), we may release with it as a Known Issue. @p{»»}

  @p{««}If there are any Berkeley DB database experts reading this we could
  use your help figuring out what the heck is going on...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1536}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-29 13:45:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69423.msg825779@s{hash}msg825779
@section 3 {tx}

  @p{««}If 'tainted coin tracing' is ever implemented, it would be pretty
  easy to extend the idea to 'tainted mined coins'. @p{»»}

  @p{««}Mine 75 BTC (50 plus 25 in 'melted, tainted coins') and it'd be
  considered 33% tainted. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1537}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-29 13:58:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=69423.msg825799@s{hash}msg825799
@section 3 {tx}

  @p{««}My point was ANY scheme you come up with will eventually come down
  to "Does this transaction input have a high enough percentage of
  'badness' for me to say no, I won't take it." @p{»»}

  @p{««}Whatever percentage you choose, the bad guys will very likely
  figure out ways to make their transactions just barely pass your purity
  test. @p{»»}

  @p{««}Which is why I mostly think starting down that road is probably a
  bad idea. @p{»»}

  @p{««}On the other hand... "security theatre" can be good public
  relations. Make the bad guys jump through two hoops and then feel good
  about how tough you are on crime.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1538}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-30 01:37:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74641.msg826728@s{hash}msg826728
@section 3 {tx}

  @p{««}We updated the translations and fixed two
  serious-enough-to-be-showstopper bugs, and 0.6 release candidate 6 is
  available at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The two bugs (both caused by changes between release candidates 4
  and 5, of course!) were: @p{»»}

    @p{(li} 1. Creating over a gigabyte of transaction logs during initial
    blockchain download. You should now see both a fast download and no
    more than 120MB of log files created. @p{li)}

    @p{(li} 2. A few people upgrading from previous releases couldn't get
    past the 'loading addr.dat' phase of startup. @p{li)}

  @p{««}I hope to repackage this as the final 0.6.0 release tomorrow; if
  you can help sanity test, please do! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1539}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-30 15:17:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74641.msg827480@s{hash}msg827480
@section 3 {tx}

  @p{««}Thanks for the help sanity testing, I've repackaged the rc6 bits as
  version 0.6.0. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1540}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-30 15:19:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74737.msg827484@s{hash}msg827484
@section 3 {tx}

  @p{««}Bitcoin version 0.6.0 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This release includes more than 20 language localizations. @p{brk}
  More translations are welcome; join the @p{brk} project at Transifex to
  help: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Project source code is hosted at github; we are no longer @p{brk}
  distributing .tar.gz files here, you can get them @p{brk} directly from
  github: @p{brk} @s{(link)} @s{hash} .tar.gz @p{brk} @s{(link)} @s{hash} .zip @p{»»}

  @p{««}For Ubuntu users, there is a ppa maintained by Matt Corallo which
  @p{brk} you can add to your system so that it will automatically keep
  @p{brk} bitcoin up-to-date. Just type @p{brk} sudo apt-add-repository
  ppa:bitcoin/bitcoin @p{brk} in your terminal, then install the
  bitcoin-qt package. @p{»»}

  @p{««} KNOWN ISSUES @p{»»}

  @p{««}Shutting down while synchronizing with the network @p{brk}
  (downloading the blockchain) can take more than a minute, @p{brk}
  because database writes are queued to speed up download @p{brk} time.
  @p{»»}

  @p{««} NEW FEATURES SINCE BITCOIN VERSION 0.5  @p{»»}

  @p{««}Initial network synchronization should be much faster @p{brk} (one
  or two hours on a typical machine instead of ten or more @p{brk} hours).
  @p{»»}

  @p{««}Backup Wallet menu option. @p{»»}

  @p{««}Bitcoin-Qt can display and save QR codes for sending @p{brk} and
  receiving addresses. @p{»»}

  @p{««}New context menu on addresses to copy/edit/delete them. @p{»»}

  @p{««}New Sign Message dialog that allows you to prove that you @p{brk}
  own a bitcoin address by creating a digital @p{brk} signature. @p{»»}

  @p{««}New wallets created with this version will @p{brk} use 33-byte
  'compressed' public keys instead of @p{brk} 65-byte public keys,
  resulting in smaller @p{brk} transactions and less traffic on the
  bitcoin @p{brk} network. The shorter keys are already supported @p{brk}
  by the network but wallet.dat files containing @p{brk} short keys are
  not compatible with earlier @p{brk} versions of Bitcoin-Qt/bitcoind.
  @p{»»}

  @p{««}New command-line argument -blocknotify=@p{lt}command@s{gt} @p{brk}
  that will spawn a shell process to run @p{lt}command@s{gt} @p{brk} when
  a new block is accepted. @p{»»}

  @p{««}New command-line argument -splash=0 to disable @p{brk} Bitcoin-Qt's
  initial splash screen @p{»»}

  @p{««}validateaddress JSON-RPC api command output includes @p{brk} two
  new fields for addresses in the wallet: @p{brk} pubkey : hexadecimal
  public key @p{brk} iscompressed : true if pubkey is a short 33-byte key
  @p{»»}

  @p{««}New JSON-RPC api commands for dumping/importing @p{brk} private
  keys from the wallet (dumprivkey, importprivkey). @p{»»}

  @p{««}New JSON-RPC api command for getting information about @p{brk}
  blocks (getblock, getblockhash). @p{»»}

  @p{««}New JSON-RPC api command (getmininginfo) for getting @p{brk} extra
  information related to mining. The getinfo @p{brk} JSON-RPC command no
  longer includes mining-related @p{brk} information
  (generate/genproclimit/hashespersec). @p{»»}

  @p{««}NOTABLE CHANGES  @p{»»}

  @p{««}BIP30 implemented (security fix for an attack involving @p{brk}
  duplicate "coinbase transactions"). @p{»»}

  @p{««}The -nolisten, -noupnp and -nodnsseed command-line @p{brk} options
  were renamed to -listen, -upnp and -dnsseed, @p{brk} with a default
  value of 1. The old names are still @p{brk} supported for compatibility
  (so specifying -nolisten @p{brk} is automatically interpreted as
  -listen=0; every @p{brk} boolean argument can now be specified as either
  @p{brk} -foo or -nofoo). @p{»»}

  @p{««}The -noirc command-line options was renamed to @p{brk} -irc, with a
  default value of 0. Run -irc=1 to @p{brk} get the old behavior. @p{»»}

  @p{««}Three fill-up-available-memory denial-of-service @p{brk} attacks
  were fixed. @p{»»}

  @p{««}NOT YET IMPLEMENTED FEATURES  @p{»»}

  @p{««}Support for clicking on bitcoin: URIs and @p{brk} opening/launching
  Bitcoin-Qt is available only on Linux, @p{brk} and only if you configure
  your desktop to launch @p{brk} Bitcoin-Qt. All platforms support
  dragging and dropping @p{brk} bitcoin: URIs onto the Bitcoin-Qt window
  to start @p{brk} payment. @p{»»}

  @p{««} PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS  @p{»»}

  @p{««}This release has preliminary support for multisignature @p{brk}
  transactions@p{--} transactions that require authorization @p{brk} from
  more than one person or device before they @p{brk} will be accepted by
  the bitcoin network. @p{»»}

  @p{««}Prior to this release, multisignature transactions @p{brk} were
  considered 'non-standard' and were ignored; @p{brk} with this release
  multisignature transactions are @p{brk} considered standard and will
  start to be relayed @p{brk} and accepted into blocks. @p{»»}

  @p{««}It is expected that future releases of Bitcoin-Qt @p{brk} will
  support the creation of multisignature transactions, @p{brk} once enough
  of the network has upgraded so relaying @p{brk} and validating them is
  robust. @p{»»}

  @p{««}For this release, creation and testing of multisignature @p{brk}
  transactions is limited to the bitcoin test network using @p{brk} the
  "addmultisigaddress" JSON-RPC api call. @p{»»}

  @p{««}Short multisignature address support is included in this @p{brk}
  release, as specified in BIP 13 and BIP 16. @p{»»}

  @p{««} Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Alex B @p{brk} Alistair Buxton @p{brk} Chris Moore @p{brk} Clark
  Gaebel @p{brk} Daniel Folkinshteyn @p{brk} Dylan Noblesmith @p{brk}
  Forrest Voight @p{brk} Gavin Andresen @p{brk} Gregory Maxwell @p{brk}
  Janne Pulkkinen @p{brk} Joel Kaartinen @p{brk} Lars Rasmusson @p{brk}
  Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk} Michael
  Hendricks @p{brk} Nick Bosma @p{brk} Nils Schneider @p{brk} Philip
  Kaufmann @p{brk} Pierre Pronchery @p{brk} Pieter Wuille @p{brk} Rune K
  Svendsen @p{brk} Wladimir J. van der Laan @p{brk} coderrr @p{brk} p2k
  @p{brk} sje397 @p{»»}

  @p{««}Special thanks to Sergio Lerner and Matt Corallo for bringing
  @p{brk} potential denial-of-service attacks to our attention. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1541}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-30 22:26:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74737.msg828115@s{hash}msg828115
@section 3 {tx}

  @s{quotedtext}

  @p{««}When the maintainer (Matt) has a little time. @p{»»}

  @s{quotedtext}

  @p{««}No, not yet. Anybody know if there's a web page that will do the
  verification? (would be easy to create one...) @p{»»}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1542}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-30 22:40:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74584.msg828128@s{hash}msg828128
@section 3 {tx}

  @s{quotedtext}

  @p{««}What is your definition of "truly mainstream" ? @p{»»}

  @p{««}If 1% of the world uses Bitcoin for 1% of their transactions, then
  I'd still consider it a huge success. I think there's a good chance that
  happens, but that doesn't fit my definition of 'mainstream.' @p{»»}

  @p{««}I think there is small possibility Bitcoin proper is used by a
  majority of people in some country somewhere in the world use it at
  least once a week to pay for things. I'd consider that mainstream
  success. @p{»»}

  @p{««}I think there's a tiny possibility Bitcoin will eventually become
  as popular as the dollar. @p{»»}

  @p{««}But I'm not very good at predicting the future, so you might want
  to consult you local fortune teller. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1543}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-31 16:15:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74584.msg829147@s{hash}msg829147
@section 3 {tx}

  @s{quotedtext}

  @p{««}I don't know nuthin about pricing risk, which is why I tell all of
  my relatives I have absolutely no idea whether or not they should buy
  Bitcoins. @p{»»}

  @p{««}But: it seems to me you're assuming that the entire $5 current
  price of Bitcoin is pure speculation, and ignoring that they ARE
  functioning as money in some fledgling markets. And don't you have to
  factor in time value of money into the calculation? I'll pay a lot more
  for bitcoin today if I think there's a 30% chance it will be worth $600
  in a year than if I think there is a 30% chance in 100 years. @p{»»}

  @p{««}You're also assuming that the velocity of bitcoin will be
  approximately equal to the velocity of traditional currencies. I could
  image it being much higher (less friction in transactions, so more
  transactions) or much lower (maybe bitcoin will be used mostly as a
  long-term store of value, with infrequent transactions; what is the
  velocity of an gram of gold compared to dollars?). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1544}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-31 23:28:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74897.msg829581@s{hash}msg829581
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, you should insist that customers give you a refund/cash-out
  address BEFORE you give them the funding address. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1545}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-03-31 23:41:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71282.msg829599@s{hash}msg829599
@section 3 {tx}

  @s{quotedtext}

  @p{««}About 20 minutes until the deadline... I expect to hear some very
  loud complaining about "I wasted a bunch of time generating orphan
  blocks why didn't you WARN me!" in the next few days. This is not an
  elaborate April Fool's joke. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1546}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-02 15:38:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75068.msg831853@s{hash}msg831853
@section 3 {tx}

  @p{««}Summarizing a discussion from @s{hash}bitcoin-dev this morning: @p{»»}

  @p{««}The merge window for pull requests for a 0.6.1 release is now open.
  @p{»»}

  @p{««}This will be a bug-fix and code-cleanup only release, with the goal
  to have Release Candidate 1 binaries available for testing in three
  weeks: April 23'rd. We want this to be a quick release cycle so we can
  start pulling new features for a 0.7 release in a month or so. @p{»»}

  @p{««}The major issues I would like to get resolved: @p{brk} @s{hash} 1024
  Correct passphrase crashed the client @p{brk} @s{hash} 1012 bitcoin-qt slow to
  shut down after recent commits @p{»»}

  @p{««}There are currently 189 open issues in our bug tracker; lets try to
  get that down to under 100. @p{»»}

  @p{««}I know this will frustrate some of you who think development is
  happening at a snail's pace; feel free to pull and test new features
  (IPv6 support and coin control) that are important to you. Adequate
  testing is still our biggest issue, if you want your favorite feature to
  get into bitcoin core faster please spend some time helping test other
  people's favorite features. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1547}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-03 00:39:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=70074.msg832551@s{hash}msg832551
@section 3 {tx}

  @p{««}Multisignature adoption has to follow a multi-step process: @p{»»}

    @p{(li} 1. A majority of miners have to put multisignature
    transactions into blocks so they get confirmed. @p{li)}

    @p{(li} 2. A significant fraction of everybody else has to relay
    multisignature transactions so they reliably get to the miners
    (preferably more than 50%). @p{li)}

    @p{(li} 3. Depending on what you're using multisig FOR (escrow? secure
    wallets?), more technical infrastructure will need to be built.
    @p{li)}

    @p{(li} 4. After all of the above is done... y'all will be able to
    reliably use multisignature transactions. @p{li)}

  @p{««}April 1'st was the first step and we're doing pretty well with the
  second step, version 0.6 has a lot of support on the network already. In
  fact, it is going so well I think we should turn on the
  'addmultisigaddress' JSON-RPC method so people can start creating and
  experimenting with multisig with the 0.6.1 release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1548}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-03 13:47:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75159.msg833332@s{hash}msg833332
@section 3 {tx}

  @p{««}Upgrade to 0.6. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1549}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-03 16:54:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75159.msg833668@s{hash}msg833668
@section 3 {tx}

  @s{quotedtext}

  @p{««}Nope, sorry, have higher priority things to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1550}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-05 16:50:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75481.msg836901@s{hash}msg836901
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think it is really important that the bitcoins involved in
  failed escrows not be destroyed, but EVENTUALLY make their way back into
  the economy. @p{»»}

  @p{««}So I'd really like to see network and client support for having
  both people pre-sign and hold on to a transaction with a
  far-in-the-future lockTime (maybe as a fee-only transaction).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1551}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-05 17:58:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74737.msg837011@s{hash}msg837011
@section 3 {tx}

  @s{quotedtext}

  @p{««}All righty... you're the first person I've heard that from. @p{»»}

  @p{««}Please file bug reports on the github issue tracker. Include enough
  information so we can reproduce the problem (what platform? what seems
  to cause the problem? etc) and it might get fixed. @p{»»}

  @p{««}I say "might" because if you're serving up a big mining pool
  running bitcoind on Windows... well, none of the current core developers
  work on Windows. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1552}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-06 00:01:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75441.msg837707@s{hash}msg837707
@section 3 {tx}

  @s{quotedtext}

  @p{««} If I'm reading their specs correctly, if A manages to break the
  chip she could generate duplicate transactions for the full value stored
  on the chip to B and C and D (and E and F and...). @p{»»}

  @p{««}But she wouldn't be able to double-spend the same funds to B,
  because B's chip is able to detect that attempted double-spend. @p{»»}

  @p{««}Eventually, I assume the Mint would figure out that the same funds
  were spent at B and C and D and... etc, just like the Mint eventually
  figures out when a lot of counterfeit paper notes are being spent in a
  particular area. And I imagine they'd deal with it the same way,
  interviewing merchants to ask them if they have a record of who made a
  transaction at a particular time, etc. @p{»»}

  @p{««}And assuming B/C/D/... did nothing wrong I bet the Mint honors all
  of the the A -@s{gt} B/C/D/... transactions, so B/C/D/... don't lose any
  money. The Mint eats the loss (it just shows up as inflation in the
  money supply, so really EVERYBODY pays for the fraud), and if the
  problem gets large enough they declare version 1.0 of their chips
  obsolete and come out with a New and More Secure version. @p{»»}

  @p{««}It all looks pretty nifty to me, I hope it is a big success; it
  could be a great way to buy Bitcoins (non-reversible, cash-like...).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1553}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-06 16:06:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75481.msg838649@s{hash}msg838649
@section 3 {tx}

  @s{quotedtext}

  @p{««} @s{(link)} : I created it as a 'private' gist because it is only
  half-baked. @p{»»}

  @p{««}RE: lockTime and the memory pool: @p{»»}

  @p{««}Note: I'm using an "Alice pays Bob" scenario as described in the
  above gist: @p{»»}

  @p{««}If neither party is cheating, then the pre-signed DISPUTE should
  NOT get broadcast until there really is a dispute. Instead, Alice and
  Bob's clients hold on to it. @p{»»}

  @p{««}So it is not in any miner's memory pools, and if there is no
  dispute nobody besides the two people involved in the transaction ever
  know about it. @p{»»}

  @p{««}Of course we have to assume that people WILL try to cheat, so the
  question becomes: what if Alice or Bob broadcasts DISPUTE prematurely?
  Would anything bad happen? @p{»»}

  @p{««}I believe the answer is no, assuming Bob waits for transactions to
  be confirmed. If DISPUTE is in "everybody's" memory pool, then any other
  transaction involving the escrowed funds will just be ignored. Even if
  Bob's client didn't see the DISPUTE broadcast (maybe he was offline) but
  later saw the SUCCESS transaction broadcast from Alice, SUCCESS would
  never be confirmed. @p{»»}

  @p{««}On the other hand, if not "everybody" has the DISPUTE transaction
  in their memory pool and Alice broadcasts SUCCESS, then it will likely
  be picked up by a miner and confirmed. Once it is in a block, the
  conflicting DISPUTE transaction gets dropped from everybody's memory
  pool as a failed double-spend. Given the churn in the nodes connected to
  the network, I expect this would actually be the most common case. @p{»»}

  @p{««}If Bob's client does see DISPUTE broadcast, it should probably let
  Bob know that Alice is unhappy and has disputed the transaction. @p{»»}

  @p{««}DISPUTE (which will be given a non-final sequence number) cannot
  get into a block until after lockTime. @p{»»}

  @p{««} @p{hrule} All of the above is based on my best understanding of
  how the Satoshi code works right now; prototyping and experimenting on
  the testnet would be a good next step to make sure it actually behaves
  the way I think. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1554}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-07 00:02:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74737.msg839321@s{hash}msg839321
@section 3 {tx}

  @p{««}Is anybody else seeing anything like what jetmine is seeing?
  Anybody else running CentOS 5.6? Did you compile from source or are you
  using the binaries we compiled? @p{»»}

  @p{««}My 0.6 nodes running on Ubuntu 11 have been rock solid. @p{»»}

  @p{««}The "CBlock::ReadFromDisk() : OpenBlockFile failed" is very odd,
  that should never happen. You aren't running with a -datadir on a
  network drive or something are you? @p{»»}

  @p{««}RE: filling addr.dat: that is one of the denial-of-service attacks
  fixed by the 0.6 release.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1555}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-07 00:57:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75481.msg839378@s{hash}msg839378
@section 3 {tx}

  @s{quotedtext}

  @p{««}Well, if DISPUTE is a fee-only transaction then miners have a VERY
  strong incentive to drop LAZY_ALICE and mine DISPUTE instead. I don't
  think we'd have trouble asking miners to support a code change that is
  something like: @p{»»}

  @s{quotedtext}

  @p{««} etotheipi, I've been thinking about your comment "I don't like the
  asymmetry" ... @p{brk} LAZY_ALICE and DISPUTE are, I think,
  symmetric@p{--} Alice holds DISPUTE in case Bob doesn't hold up his end
  of the bargain, Bob holds LAZY_ALICE in case she doesn't. I proposed
  that DISPUTE have an earlier lockTime than LAZY_ALICE, but maybe that's
  not necessary. @p{»»}

  @p{««}If Alice @p{(it}really@p{it)} doesn't trust Bob, then I think the
  whole scheme also works if Bob puts a "good faith security deposit" of
  bitcoins into the mix. @p{»»}

  @p{««} @p{hrule} @p{brk} The complexity of all this (5 possible
  transactions, different states the escrow can be in, initial
  communication to initiate the escrow) makes me nervous. Even just
  figuring out how Alice and Bob's clients talk to each to setup the
  escrow isn't obvious. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1556}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-08 15:03:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75481.msg841500@s{hash}msg841500
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, if Bob puts in a deposit it adds a step internally. @p{»»}

  @p{««}I think for this to have a reasonable user-interface Alice and
  Bob's bitcoin clients will need to communicate in real time. @p{»»}

  @p{««}My inclination is to add JSON-RPC methods to bitcoin-qt/bitcoind to
  support this, and not build it into bitcoin-qt's GUI (or at least not
  right away). I'm imagining Armory or little "let's make a deal"
  2-party-escrow-apps that... Do The Right Thing. @p{»»}

  @p{««}Random UI thoughts: @p{»»}

  @p{««}Alice could be asked "How much do you trust Bob?" and "How much do
  you think Bob trusts you?" If an answer is "not at all" then propose an
  escrow that requires a substantial deposit. If the answer is "a lot"
  then maybe no deposit is required. It'd be way spiffy cool if it was
  automagically tied into the @s{hash}bitcoin-otc web of trust sytem... @p{»»}

  @p{««}(... more random thoughts: would IRC as the communication mechanism
  under the covers be a good or bad idea? might be a convenient way to
  prototype...) @p{»»}

  @p{««}I'm imagining Bob gets the details of the proposed escrow and can
  either agree or disagree (maybe with a message to let Alice know what he
  WOULD agree to). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1557}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-08 15:13:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20799.msg841506@s{hash}msg841506
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}Personally, I consider the coin creation function (50 BTC every 10
  minutes, halving every 4 years) and rules for whether or not you can
  spend the coins you have (if, and only if, you can satisfy the
  scriptPubKey by creating an ECDSA signature then you can spend them)
  sacrosanct. Them's the rules of Bitcoin, change them and it ain't
  Bitcoin any more. @p{»»}

  @p{««}Extending Bitcoin to new and wonderful types of transactions is
  fine, and, actually, I believe Therilith could build most of what he
  wants on top of Bitcoin using pre-signed fee-only non-final transactions
  with a lockTime 10 years in the future. @p{»»}

  @p{««}Convincing people to agree to do that would be another thing all
  together... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1558}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-08 19:06:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=20799.msg841749@s{hash}msg841749
@section 3 {tx}

  @s{quotedtext}

  @p{««}Write up a proposal, start experimenting on testnet, recruit people
  to think really hard about how whether or not what you're proposing
  could be abused to compromise security or could make a denial-of-service
  attack easier... @p{»»}

  @p{««}I'm against changes that @p{(it}might@p{it)} make Bitcoin a tiny
  bit better, but if you've got a well-thought-out proposal for how to
  make Bitcoin much better in some way then I'll help you argue for it.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1559}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-08 19:24:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74737.msg841776@s{hash}msg841776
@section 3 {tx}

  @s{quotedtext}

  @p{««}Thanks, that should be very helpful. I opened issue @s{hash}1065
  @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms1560}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-10 18:37:37 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67739.msg845100@s{hash}msg845100
@section 3 {tx}

  @s{quotedtext}

  @p{««}In the long run, I think we have to assume that miners will do what
  is most profitable, and design escrow/payment protocols around that
  assumption. @p{»»}

  @p{««}Replacing non-final transactions in the memory pool potentially
  opens up a whole bucket of worms, but I think the short-term challenge
  is to figure out if we should change the rules we have now. If we do (I
  think we should), then I think it would be a mistake to do anything
  other than "create rules that will maximize miner profits." Because if
  we do something else, then sooner or later I believe there
  @p{(bf}will@p{bf)} be a "miners special" version of the code that has
  miner-friendly rules. @p{»»}

  @p{««} @p{hrule} If you agree with me that the default rules in the
  client should maximize miners' profits, then it seems to me there's one
  simple rule change we should make: @p{»»}

  @p{««}If you've got two otherwise equivalent transactions that spend the
  same input(s), keep the one with the most fees. @p{»»}

  @p{««}Right now, the rule is "keep the first one you see." @p{»»}

  @p{««}The bag of worms comes into play if you've got two transactions
  that spend the same input(s) that, for example, look like this: @p{»»}

  @p{««}Transaction 1: final transaction (can go into a block RIGHT NOW)
  that has a fee of 0.005 BTC @p{brk} Transaction 2: transaction that
  won't be final for 3 days that has a fee of 0.1 BTC @p{»»}

  @p{««}Should a miner put Transaction 1 into the block they're mining and
  take the smaller fee now, or not include it, hoping that nobody else
  mines Transaction 1 in the next 3 days so maybe they can mine
  Transaction 2 and get the bigger fee? @p{»»}

  @p{««}I'm not an expert in game theory, but I believe the winning
  strategy in the above situation, assuming everybody knows about both
  transactions, is to mine Transaction 1 right away (any economists
  reading who know a lot more about game theory than I do?). @p{»»}

  @p{««}That suggests the rules for transactions that spend the same inputs
  aught to be: @p{»»}

    @p{(li} 1. If you have two free transactions, keep the first one you
  see. @p{brk} 2. If you have a free and a fee-paying transaction, always
  keep the fee-paying one. @p{brk} 3. If you have two final, fee-paying
  transactions, keep/mine/relay the one with the higher fee. @p{brk} 4. If
  one or both of the transactions is non-final, keep/relay the one that
  will become final first. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1561}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-11 01:46:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76216.msg845745@s{hash}msg845745
@section 3 {tx}

  @p{««}As I told Matthew when I spoke with him a couple of weeks ago, I
  also think this is a fantastic idea and plan on helping the CLAG however
  I can. Legal and regulatory uncertainty is perhaps the biggest barrier
  for companies who might be thinking of launching projects involving
  Bitcoin, and having a reliable source of up-to-date accurate information
  about the issues will be incredibly valuable. @p{»»}

  @p{««}Hopefully in a couple of years the CLAG's biggest problem will be
  figuring out what it's role should be as similar groups, inspired by the
  CLAG, spring up all over the world to tackle the unique legal issues in
  each country. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1562}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-11 18:21:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67739.msg846846@s{hash}msg846846
@section 3 {tx}

  @s{quotedtext}

  @p{««}Some of the big mining pool operators are already going their own
  way, experimenting with new types of transactions (e.g. deepbit and
  eligius), so I suspect the answer to your question "Can 'we' please hold
  off..." is "No." @p{»»}

  @p{««}Discussions like this one are how I start to understand parts of
  the protocol like nLockTime and transaction replacement better. @p{»»}

  @p{««} As for BIP 16 draining effort away from making the standard client
  scale: I've been saying for a year that my top priorities are network
  stability and wallet security. Making the standard client scale is, in
  my opinion, a lower priority; I don't want a super-scalable client with
  a 4-minute blockchain initial block sync time if it is vulnerable to the
  user clicking one wrong link and getting infected by a trojan wallet
  stealer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1563}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-12 16:22:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67739.msg848210@s{hash}msg848210
@section 3 {tx}

  @s{quotedtext}

  @p{««}The Bitcoin ecosystem consists of more that just miners, and even
  if miners decided to try to form a cabal to increase inflation
  merchants, users, and exchanges could all veto their block-chain by
  simply refusing to recognize it. @p{»»}

  @p{««}I think the policy of which transactions to keep in the memory pool
  is fundamentally different, because miners can do whatever they like and
  there's not a whole lot merchants/users/exchanges or other miners can do
  about it. There's no way to enforce a "first broadcast version of a
  transaction must be mined" rule, if there was then we wouldn't need the
  block chain at all. @p{»»}

  @p{««}As for re-writing the blockchain if an after-the-fact, large-fee
  double-spend is broadcast: I think that's covered by this case: @p{»»}

  @s{quotedtext}

  @p{««}Or, in other words, you'd need to be pretty sure that you've got a
  majority of miners who will cooperate with you to rewrite the block
  chain. The longer the chain, the harder that will be (because it becomes
  increasingly likely that one of your co-conspirators mined one of the
  blocks you want to overwrite).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1564}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-12 17:30:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76416.msg848296@s{hash}msg848296
@section 3 {tx}

  @p{««}Split from the press hits topic: @p{»»}

  @p{««}The only "skeleton key" I have is the private key for alert
  messages, that lets me sign messages that are broadcast and then
  displayed in the client (see @s{(link)} for details, and the alerts that
  have been sent). @p{»»}

  @p{««}MAYBE he is saying that the core developers could slip in a change
  to the source code without anybody else noticing... but we've worked
  hard to make that impossible (with things like the gitian reproducible
  build system so people can verify that we are creating executables from
  the source code that anybody can look at). @p{»»}

  @p{««}Smells like plain-old FUD to me.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1565}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-12 17:39:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=67739.msg848314@s{hash}msg848314
@section 3 {tx}

  @s{quotedtext}

  @p{««}Or maybe you should wait 60 blocks before considering a
  half-a-million-dollar transaction final if you think there is any
  possibility of a mining cabal trying to do this. @p{»»}

  @p{««}All of this reminds me, I need to clean up my
  user-defined-checkpoints code for the 0.7 release, so a cabal of
  merchants and exchanges can get together and decide they will "lock in"
  an agreed-upon blockchain after 6 (or 60 or whatever) confirmations. I
  think that would go a long way towards infrastructure for injecting
  real-world knowledge about who is trustworthy into the block-chain.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1566}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-13 21:01:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76449.msg850099@s{hash}msg850099
@section 3 {tx}

  @p{««}RE: $100 per-transaction, $500 balance limit: @p{»»}

  @p{««}That makes perfect sense; they probably figured out about how much
  it will cost to hack a MintChip to get it's private key (dissolve case
  in acid, put it under an electron microscope, attach electrodes at
  exactly the right spots, etc...). Do a little calculation involving the
  cost of hacking one chip, the number of times you can double-spend
  before you're likely to get caught and the maximum amount per
  transaction and I bet they figure it doesn't pay. @p{»»}

  @p{««}Especially if online transactions "phone home" to detect
  double-spends. If you have to physically walk to 500 different
  not-online merchants to get away with $50,000 worth of double-spends
  that's just like counterfeiting $100 bills, and that's an attack Mints
  have been pretty successfully dealing with for hundreds of years. @p{»»}

  @p{««}RE: anonymity: the anonymity model is similar to Bitcoin. Each
  physical MintChip is like a Bitcoin keypair, if you can easily buy/load
  a bunch of them anonymously then it will be hard for Them to track your
  purchases. @p{»»}

  @p{««}If MintChip fails I bet it is not due to hacking or lack of
  anonymity, but just due to the inconvenience of needing Yet Another
  Physical Doohickey. Paper money fits nicely into the wallet I already
  have, I don't want Yet Another Dongle on my keychain, and I bet before
  the end of the year either Apple will finally approve a Bitcoin app or
  there will be a nifty HTML5-based web wallet I can use on my iPhone...
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1567}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-14 23:22:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76449.msg851407@s{hash}msg851407
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good question. They're the Mint, so I bet they'll handle that the
  same way they handle somebody showing up at a bank with a bunch of
  counterfeit $100 bills: they'll ask you where you got them, and either
  throw you in jail (if they don't like your story) or tell you to be more
  careful about who you deal with and maybe direct you to some technology
  to help detect counterfeits in the future. But they won't let you
  deposit them or trade your bad money for good. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1568}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-18 13:41:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77148.msg856993@s{hash}msg856993
@section 3 {tx}

  @p{««}Better testing, both for the Satoshi code and across different
  implementations, is right at the top of my priority list. So I wrote
  some code to make it easier to exercise edge cases in Script evaluation:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The unit tests are data-driven by two files: @p{brk}
   script_valid.json contains pairs of (scriptSig,scriptPubKey) that, when
   used in a transaction, should evaluate to true. @p{brk}
   script_invalid.json contains pairs that are invalid for some reason.
   @p{»»}

  @p{««}I'm looking for help to expand those to cover all the quirky edge
  cases that might trip up alternative "fully validating" implementations
  (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how
  best to write test cases for those). If you can help, please jump in and
  write some more. Assuming you've got the bitcoin source tree cloned the
  process for adding new tests is easy: @p{»»}

    @p{(li} 1. Edit src/test/data/script*.json @p{brk} 2. From the src/
  directory run: @p{li)}

    @p{(li} make -f makefile.unix test_bitcoin @p{li)} 3. Run the unit
  tests with: ./test_bitcoin @p{»»}

  @p{««}Or if you've already got Script test cases in some other
  human-readable form please point me to them. @p{»»}

  @p{««}I'm planning on resetting the testnet with a new genesis block and
  a chain that contains all of the valid tests as spent transactions (and
  a checkpoint so all those nice test cases aren't overwritten). @p{»»}

  @p{««}It would be really nifty to have a 'bad chain' node running;
  -connect to it and it would send you otherwise-valid blocks that
  contained one or more of the invalid transactions from
  script_invalid.json. Does that sound like a project any of you would
  like to tackle?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1569}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-19 18:36:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=71282.msg859315@s{hash}msg859315
@section 3 {tx}

  @s{quotedtext}

  @p{««}We should have, but "we" didn't think of that in time. @p{»»}

  @p{««}I've been working on a "how to do it better next time" document:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1570}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-19 22:47:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77312.msg859667@s{hash}msg859667
@section 3 {tx}

  @s{quotedtext}

  @p{««}I agree with Andrew. Building a website that handles money is a
  terrible first project. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1571}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-20 15:10:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77422.msg860686@s{hash}msg860686
@section 3 {tx}

  @p{««}Cross-posted from the Alternative Clients sub-forum, since it looks
  like the alternative client folks are more interested in adding new
  features than figuring out exactly how the features we already have
  work: @p{»»}

  @p{««}Better testing, both for the Satoshi code and across different
  implementations, is right at the top of my priority list. So I wrote
  some code to make it easier to exercise edge cases in Script evaluation:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The unit tests are data-driven by two files: @p{brk}
   script_valid.json contains pairs of (scriptSig,scriptPubKey) that, when
   used in a transaction, should evaluate to true. @p{brk}
   script_invalid.json contains pairs that are invalid for some reason.
   @p{»»}

  @p{««}I'm looking for help to expand those to cover all the quirky edge
  cases that might trip up alternative "fully validating" implementations
  (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how
  best to write test cases for those). If you can help, please jump in and
  write some more. Assuming you've got the bitcoin source tree cloned the
  process for adding new tests is easy: @p{»»}

    @p{(li} 1. Edit src/test/data/script*.json @p{brk} 2. From the src/
  directory run: @p{li)}

    @p{(li} make -f makefile.unix test_bitcoin @p{li)} 3. Run the unit
  tests with: ./test_bitcoin @p{»»}

  @p{««}Or if you've already got Script test cases in some other
  human-readable form please point me to them. @p{»»}

  @p{««}I'm planning on resetting the testnet with a new genesis block and
  a chain that contains all of the valid tests as spent transactions (and
  a checkpoint so all those nice test cases aren't overwritten). @p{»»}

  @p{««}It would be really nifty to have a 'bad chain' node running;
  -connect to it and it would send you otherwise-valid blocks that
  contained one or more of the invalid transactions from
  script_invalid.json. Does that sound like a project any of you would
  like to tackle?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1572}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-23 17:03:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76073.msg864900@s{hash}msg864900
@section 3 {tx}

  @s{quotedtext}

  @p{««}Of course fungibility is important. @p{»»}

  @p{««}But fungibility isn't all-or-nothing, and, in my humble opinion, it
  isn't all-important. Refusing to accept dollar bills or bitcoins that
  you believe were obtained illegally makes them less fungible, but so
  what? It's the right thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1573}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-25 00:42:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=29256.msg867493@s{hash}msg867493
@section 3 {tx}

  @p{««}I pinky-swear on a stack of bibles I haven't heard a peep from
  Satoshi. @p{»»}

  @p{««}Whatever he/she/they have been busy doing, I guess he/she/they're
  still busy doing it. Or maybe doobadoo is Satoshi and is trying to
  misdirect us....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1574}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-25 00:58:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=75696.msg867506@s{hash}msg867506
@section 3 {tx}

  @s{quotedtext}

  @p{««}There's one selling for about 2 BTC (equivalent) here: @s{(link)}
  @p{»»}

  @p{««}I wonder how that compares to the inflation-adjusted buggy-whip
  price in 1900...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1575}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-25 15:32:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77652.msg868199@s{hash}msg868199
@section 3 {tx}

  @s{quotedtext}

  @p{««}I have a -noprivacy patch that I use for the Faucet that
  accomplishes what you want, sending any change back to the funding
  address. @p{»»}

  @p{««}It isn't part of the core code because it doesn't play nicely with
  other features (accounts and listtransactions, for example). See
  @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1576}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-25 15:38:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77853.msg868209@s{hash}msg868209
@section 3 {tx}

  @p{««}I blogged about the CoinLab deal (the post wanders off into
  bigger-picture economics thoughts at the end): @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1577}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-29 21:24:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78403.msg874553@s{hash}msg874553
@section 3 {tx}

  @p{««}If a 51% attacker stopped including all broadcast transactions in
  blocks "we" would quickly figure out a rule or rules to reject their
  blocks. @p{»»}

  @p{««}Something like "ignore a longer chain orphaning the current best
  chain if the sum(priorities of transactions included in new chain) is
  much less than sum(priorities of transactions in the part of the current
  best chain that would be orphaned)" would mean a 51% attacker would have
  to have both lots of hashing power AND lots of old, high-priority
  bitcoins to keep up a transaction-denial-of-service attack. And they'd
  pretty quickly run out of old, high-priority bitcoins and would be
  forced to either include other people's transactions or have their chain
  rejected. @p{»»}

  @p{««}I'm tempted to code that up and run some tests on a
  testnet-in-a-box, but there are much higher priority things on my TODO
  list; I don't think a 51% attack is likely. You'd spend a lot of time
  and money on an attack that "we" would neuter within a day or two. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1578}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-04-30 01:28:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78270.msg874869@s{hash}msg874869
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. And yes.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1579}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-01 13:02:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=47417.msg877038@s{hash}msg877038
@section 3 {tx}

  @s{quotedtext}

  @p{««}Network effect. @p{»»}

  @p{««}More developers are working on Bitcoin, there are more interesting
  projects, more useful tools, more documentation at places like
  bitcoin.stackexchange.com, etc. And that all builds on itself.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1580}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-01 20:23:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78829.msg877622@s{hash}msg877622
@section 3 {tx}

  @p{««}Bitcoin version 0.6.1rc2 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix and code-cleanup release, with no major new
  features. @p{»»}

  @p{««}NOTABLE CHANGES  @p{»»}

  @p{««}Much faster shutdowns. However, the blkindex.dat file is no longer
  @p{brk} portable to different data directories by default. If you need a
  @p{brk} portable blkindex.dat file then run with the new -detachdb=1
  option @p{brk} or the "Detach databases at shutdown" GUI preference.
  @p{»»}

  @p{««}Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
  @p{brk} binaries are dynamically linked to the version of OpenSSL on the
  system). @p{»»}

  @p{««} CHANGE SUMMARY@p{»»}

  @p{««}Use 'git shortlog @p{--}no-merges v0.6.0..' for a summary of this
  release. @p{»»}

  @p{««}Source codebase changes: @p{brk} - Many source code cleanups and
  warnings fixes. Close to building with -Wall @p{brk} - Locking overhaul,
  and several minor locking fixes @p{brk} - Several source code
  portability fixes, e.g. FreeBSD @p{»»}

  @p{««}JSON-RPC interface changes: @p{brk} - addmultisigaddress enabled
  for mainnet (previously only enabled for testnet) @p{»»}

  @p{««}Network protocol changes: @p{brk} - protocol version 60001 @p{brk}
  - added nonce value to "ping" message (BIP 31) @p{brk} - added new
  "pong" message (BIP 31) @p{»»}

  @p{««}Backend storage changes: @p{brk} - Less redundant database
  flushing, especially during initial block download @p{brk} - Shutdown
  improvements (see above) @p{»»}

  @p{««}Qt user interface: @p{brk} - minor URI handling improvements
  @p{brk} - progressbar improvements @p{brk} - error handling improvements
  (show message box rather than console exception, @p{»»}

    @p{(li}etc.) @p{li)} - by popular request, make 4th bar of connection
  icon green @p{»»}

  @p{««}Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Chris Moore @p{brk} Dwayne C. Litzenberger @p{brk} Gavin Andresen
  @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk}
  Philip Kaufmann @p{brk} Pieter Wuille @p{brk} R E Broadley @p{brk}
  Timothy Redaelli @p{brk} Wladimir J. van der Laan @p{brk} cardpuncher
  @p{brk} freewil @p{brk} graingert @p{brk} sje397 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1581}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-01 23:39:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77849.msg877942@s{hash}msg877942
@section 3 {tx}

  @s{quotedtext}

  @p{««}Interesting. @p{»»}

  @p{««}If I understand correctly, if an address has a greater-than-average
  amount of currency then it will get interest. @p{»»}

  @p{««}Paid for by all the accounts with a less-than-average amount of
  currency. @p{»»}

  @p{««}So there's an incentive for everybody to (try to) be above the
  average. That seems like a recipe for a lot of disappointed people,
  especially since a graph of size-of-account will have a long tail with
  of lots of little accounts. @p{»»}

  @p{««}Making a half-thought-out-prediction, I'd say the end result would
  likely be one big centralized account controlled by the largest exchange
  with over 50% of the currency in it, because there would be a natural
  incentive to store your money in the biggest account so you get the most
  interest...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1582}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-02 17:59:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78301.msg879277@s{hash}msg879277
@section 3 {tx}

  @p{««}I think it is a waste of time to maintain so many old versions.
  @p{»»}

  @p{««}But it's Luke's time to waste... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1583}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-03 19:35:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79105.msg880936@s{hash}msg880936
@section 3 {tx}

  @p{««}So you create a 'send' transaction: @p{»»}

  @s{code}

  @p{««} ... and you've associated msK1Hu7N27XTcuXd5MqWuyhW3YEGxHgVPe with
  the label "2_address": @p{»»}

  @s{code}

  @p{««} ... because "send" transactions always report a negative amount
  (you're sending coins) and the account that they're being sent from.
  @p{»»}

  @p{««}If you want to know the account/label associated with the address
  that you're sending to, do this: @p{»»}

  @p{««}Code: getaccount msK1Hu7N27XTcuXd5MqWuyhW3YEGxHgVPe @p{brk}
  2_address @p{»»}

  @p{««} ... or you could use the (comment)/(comment-to) params to the
  sendtoaddress/sendfrom/sendmany commands if you want the "to-account" to
  show up in listtransactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1584}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-03 19:39:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79105.msg880942@s{hash}msg880942
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, the "from" account@p{--} I think bitlane wants the "to"
  account... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1585}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-04 18:17:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79576.msg882591@s{hash}msg882591
@section 3 {tx}

  @p{««}I think this is The Idea That Will Not Die. @p{»»}

  @p{««}Bottom line: ain't gonna happen, everybody who created or purchased
  bitcoin over the last three years did so with the expectation the they
  would last forever, not that they would have some arbitrary 5-year
  expiration date. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1586}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-05 17:11:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76601.msg884030@s{hash}msg884030
@section 3 {tx}

  @p{««}That's a BIP 16 transaction: see @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1587}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 01:23:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79771.msg885847@s{hash}msg885847
@section 3 {tx}

  @p{««}See doc/build-osx.txt in the source tree for how to build bitcoind
  on osx. @p{»»}

  @p{««}See doc/readme-qt.rst for how to build Bitcoin-Qt. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1588}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 18:04:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80019.msg886899@s{hash}msg886899
@section 3 {tx}

  @p{««}Testing changes to Bitcoin-Qt continues to be a chronic problem,
  and as alternative implementations of Bitcoin start to mature testing to
  make sure that they interoperate correctly and don't harm the network
  will become a big problem. @p{»»}

  @p{««}Therefore, I'm creating a decentralized, transparent organization
  using the @p{(link}BetterMeans@p{link)} system. I'll need help from
  people willing to be fundraisers, testers, project managers, toolmakers,
  troll-catchers, etc. @p{»»}

  @p{««}I'll create and hold a secure wallet that will be used for
  donations (at least until the project gets mature enough to turn over
  that responsibility to somebody else), but we'll use the BetterMeans
  "Credits" system so that everybody working on the project
  collaboratively decides who gets what, and what the priorities aught to
  be. @p{»»}

  @p{««}So: it is easy to talk about stuff like this, who's willing to help
  make it happen? Send me an email at
  @p{(link}gavinandresen@s{at}gmail.com@p{link)} if this sounds like a project
  you'd like to help with, describing what you think the highest
  priorities for the project aught to be, how you could contribute, how
  much time you could contribute per week, and any relevant prior
  experience. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1589}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 18:15:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79830.msg886911@s{hash}msg886911
@section 3 {tx}

  @p{««}I've been procrastinating creating a "Bitcoin Testing Project" to
  fund testing work, and I was actually thinking a few days ago that
  vulnerability bounties would fit in nicely as one of the things a
  Bitcoin Testing organization would tackle. @p{»»}

  @p{««}I decided to stop procrastinating today; see my announcement here
  for a Bitcoin Testing Project: @p{»»}

    @p{(li} @s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1590}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 20:40:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80019.msg887172@s{hash}msg887172
@section 3 {tx}

  @s{quotedtext}

  @p{««}I setup the wallet this afternoon, the donation address was:
  (defunct address, don't send coins...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1591}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 21:48:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=49841.msg887270@s{hash}msg887270
@section 3 {tx}

  @p{««}I said: @p{»»}

  @s{quotedtext}

  @p{««}I like decentralized approaches, because failures are less
  catastrophic and because I think smaller, focused organizations are more
  effective than big, try-to-be-everything-to-everybody organizations.
  @p{»»}

  @p{««}So I'm happy that the @p{(link}Cryptocurrency Legal Advocacy
  Group@p{link)} is working on legal issues, starting with figuring out
  what the issues are. @p{»»}

  @p{««}And I'm happy that @p{(link}LoveBitcoins@p{link)} have been
  starting PR/Marketing efforts for Bitcoin. @p{»»}

  @p{««}Today I created the Bitcoin Testing Project to tackle some
  infrastructure needs that I think are being ignored (rigorous quality
  assurance / testing): @p{»»}

    @p{(li} @s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1592}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 22:09:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78403.msg887309@s{hash}msg887309
@section 3 {tx}

  @p{««}Miners won't switch to a 51% chain if it means they can't cash out
  the coins they're creating! @p{»»}

  @p{««}The attack we're talking about is "51% attacker refuses to include
  anybody else's transactions in their blocks." And newly generated coins
  are useless to miners if they can't get transactions that spend them
  into the block chain.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1593}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-07 22:46:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79985.msg887347@s{hash}msg887347
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}I still expect it to be a long and @p{(ul}very@p{??)} bumpy road,
  but as long as the system keeps chugging away reliably processing
  transactions I think it will, overall, in the long run, gain more and
  more trust. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1594}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 02:50:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79913.msg887602@s{hash}msg887602
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'd still like to see several somebodies who know a lot more about
  networking than I do work on transmitting Bitcoin traffic over different
  networks (along with bridge nodes to shuffle traffic between the network
  we have now and the new networks). @p{»»}

  @p{««}I'd sleep easier if I knew that an as-yet-undiscovered bug in the
  network protocol we have now couldn't bring the entire system down. I'm
  confident we'd quickly fix whatever the problem is and I'm sure it would
  be back up and running within 24 hours, but it would be better if big
  merchants and miners and services could run two or more completely
  different bitcoin-network-stacks so they're less likely to be taken down
  by DoS attacks, bugs, or ISPs deploying deep packet inspection to try to
  block Bitcoin traffic. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1595}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 16:13:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80019.msg888394@s{hash}msg888394
@section 3 {tx}

  @p{««}luke-jr : I don't want to start an argument, but I still think we
  don't have enough testing resources to support 4 releases. I think we
  need to establish good QA for the main Bitcoin-Qt/bitcoind release
  before we worry about next-test or so-called-"stable" releases. @p{»»}

  @p{««}That's a good discussion for the Testing Project team to have,
  though, once it gets up and running a little more. @p{»»}

  @p{««}I'd also like the Testing Project to not get pigeonholed into "QA
  testing for Bitcoin-Qt/bitcoind", but to tackle cross-implementation
  compatibility (which I think is the next big, critical issue).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1596}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 18:10:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78829.msg888578@s{hash}msg888578
@section 3 {tx}

  @p{««}We'll announce a 0.6.2 later today, which is just 0.6.1 plus a
  last-minute bugfix for a crashing bug (I was THIS CLOSE to formally
  announcing 0.6.1 when Pieter found and fixed the bug...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1597}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 18:20:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80126.msg888598@s{hash}msg888598
@section 3 {tx}

  @s{quotedtext}

  @p{««} See @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1598}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 18:50:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=78494.msg888645@s{hash}msg888645
@section 3 {tx}

  @p{««}On restart, you should be able to ask bitcoind for the top-of-chain
  block (using getblockcount/getblockhash/getblock). @p{»»}

  @p{««}If it's not in your database, then add it. Then look at the
  previous block hash, and if it's not in your database ask bitcoind for
  it (and so on). @p{»»}

  @p{««}To be extra safe, after you're all done ask bitcoind for the
  top-of-chain block again to see if there was a block re-org while you
  were catching up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1599}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 19:00:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80187.msg888658@s{hash}msg888658
@section 3 {tx}

  @p{««}Bitcoin version 0.6.2 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix and code-cleanup release, with no major new
  features. @p{»»}

  @p{««}Please report bugs using the github issue tracker at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}NOTABLE CHANGES  @p{»»}

  @p{««}Much faster shutdowns. However, the blkindex.dat file is no longer
  @p{brk} portable to different data directories by default. If you need a
  @p{brk} portable blkindex.dat file then run with the new -detachdb=1
  option @p{brk} or the "Detach databases at shutdown" GUI preference.
  @p{»»}

  @p{««}Fixed @s{(link)}, a bug that @p{brk} could cause long-running nodes
  to crash. @p{»»}

  @p{««}Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
  @p{brk} binaries are dynamically linked to the version of OpenSSL on the
  system). @p{»»}

  @p{««} CHANGE SUMMARY @p{»»}

  @p{««}Use 'git shortlog @p{--}no-merges v0.6.0..' for a summary of this
  release. @p{»»}

  @p{««}Source codebase changes: @p{brk} - Many source code cleanups and
  warnings fixes. Close to building with -Wall @p{brk} - Locking overhaul,
  and several minor locking fixes @p{brk} - Several source code
  portability fixes, e.g. FreeBSD @p{»»}

  @p{««}JSON-RPC interface changes: @p{brk} - addmultisigaddress enabled
  for mainnet (previously only enabled for testnet) @p{»»}

  @p{««}Network protocol changes: @p{brk} - protocol version 60001 @p{brk}
  - added nonce value to "ping" message (BIP 31) @p{brk} - added new
  "pong" message (BIP 31) @p{»»}

  @p{««}Backend storage changes: @p{brk} - Less redundant database
  flushing, especially during initial block download @p{brk} - Shutdown
  improvements (see above) @p{»»}

  @p{««}Qt user interface: @p{brk} - minor URI handling improvements
  @p{brk} - progressbar improvements @p{brk} - error handling improvements
  (show message box rather than console exception, @p{»»}

    @p{(li}etc.) @p{li)} - by popular request, make 4th bar of connection
  icon green @p{»»}

  @p{««}Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Chris Moore @p{brk} Dwayne C. Litzenberger @p{brk} Gavin Andresen
  @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk}
  Philip Kaufmann @p{brk} Pieter Wuille @p{brk} R E Broadley @p{brk}
  Timothy Redaelli @p{brk} Wladimir J. van der Laan @p{brk} cardpuncher
  @p{brk} freewil @p{brk} graingert @p{brk} sje397 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1600}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-08 23:45:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80190.msg889098@s{hash}msg889098
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yeah, but you're probably a geek and think cute cat videos have too
  little actual information, too. @p{»»}

  @p{««}The video gets a +1 from me; effective marketing appeals to
  emotion, not intellect. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1601}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-09 22:10:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80187.msg890960@s{hash}msg890960
@section 3 {tx}

  @s{quotedtext}

  @p{««}Because when I was a young child a Portuguese family lived across
  the street from me and their oldest child bullied me mercilessly, making
  fun of my haircut and my funny Australian accent. @p{»»}

  @p{««}(KIDDING! JUST KIDDING!) @p{»»}

  @p{««}Somebody to do translation quality assurance is a great idea. Want
  to volunteer? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1602}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-10 22:27:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80019.msg893221@s{hash}msg893221
@section 3 {tx}

  @p{««}Over 50 BTC in donations with no fundraising effort@p{--} thanks
  everyone who has donated so far! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1603}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-11 15:21:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80187.msg894501@s{hash}msg894501
@section 3 {tx}

  @p{««}Pieter fixed the "100% usage on OSX bug" and I created and uploaded
  a fixed version 0.6.2.2 especially for the Mac. @p{»»}

  @p{««}RE: upgrading: the best upgrade practice is to: @p{»»}

  @p{««}1) Backup your wallet someplace safe (if you're running an 0.6
  release then use the Backup Wallet menu item). @p{brk} 2) Shutdown. Make
  sure Bitcoin isn't still in your system tray@p{--} don't just close the
  window, shut it down. @p{brk} 3) Wait a minute or two (it can take older
  versions a minute or two to completely shut down) @p{brk} 4) Install and
  run the new version. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1604}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-12 15:52:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81473.msg896535@s{hash}msg896535
@section 3 {tx}

  @p{««}Do you get different answers for 'getbalance' versus 'getbalance
  "*"' ? @p{»»}

  @p{««}There is a longstanding issue with they way unconfirmed
  transactions are counted that might be the source of your problem: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1605}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-13 14:04:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81581.msg898017@s{hash}msg898017
@section 3 {tx}

  @p{««}Good luck@p{--} I share your view that coming up with better ways
  of playing zero-sum games is not the way to make the world a better
  place.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1606}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-14 01:28:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81671.msg898951@s{hash}msg898951
@section 3 {tx}

  @p{««}It seems I touched a nerve when I said that getting better at
  playing a zero-sum game isn't a good way to make the world a better
  place. @p{»»}

  @p{««}I was thinking of day-traders at the time; people who don't care
  what asset they're buying and selling but just try to buy low and sell
  high to make a profit. Or high-frequency traders who try to be just a
  tiny bit faster executing transactions to take advantage of tiny
  inefficiencies in markets. @p{»»}

  @p{««}Probably I don't have a deep enough understanding of the value of
  liquidity in asset markets or a deep enough appreciation for their role
  in creating market prices, but it seems to me the world would get along
  just fine without them spending all their time and effort competing
  against each other. @p{»»}

  @p{««}I wasn't thinking of competition in general as being a zero-sum
  game, because in general it is not. Competition drives efficiency, and
  efficiency (creating more by using less) is what makes the world a
  better place @p{--} assuming that the thing you're making more efficient
  has a positive effect on the world. Competing to build the most
  efficient bomb or assault rifle is not a world-improving activity. @p{»»}

  @p{««}To bring it back to Bitcoin: competition between Bitcoin miners is
  a zero-sum game @p{(it}for the miners@p{it)}, but if you think that
  Bitcoin will make the world a better place (I do) then the competition
  to be more efficient at mining is a net positive for the world as a
  whole. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1607}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-14 13:50:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81671.msg899652@s{hash}msg899652
@section 3 {tx}

  @p{««}I'm definitely not in the "speculators are evil" camp. Speculation
  for the right reasons (hedging risk, for example) is a very good thing.
  @p{»»}

  @p{««}I personally think speculation for the thrill of gambling is not a
  good thing, but I'm also not in the "Every Bad Thing (where I get to
  decide what Bad and Good is) Should Be Illegal" camp. If you want to
  gamble you should be free to do so; I think it is stupid that we let
  rich people on Wall Street gamble with other people's money and yet have
  laws that make it illegal for not-so-rich people to gamble with their
  own money. @p{»»}

  @p{««}From his post, Tong thought about Bitcoinica and decided that he
  could be more effective at making the world a better place by working on
  something else that is more obviously positive-sum. Good for him! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1608}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-14 16:56:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81749.msg899957@s{hash}msg899957
@section 3 {tx}

  @p{««}We have been quietly notifying the largest exchanges, merchant
  service providers and mining pools about this issue, and waited until
  they upgraded or patched their code to go public with this: @p{»»}

  @p{««}CVE-2012-2459: Critical Vulnerability @p{»»}

  @p{««}A denial-of-service vulnerability that affects all versions of
  @p{brk} bitcoind and Bitcoin-Qt has been reported and fixed. An attacker
  @p{brk} could isolate a victim's node and cause the creation of
  blockchain @p{brk} forks. @p{»»}

  @p{««}Because this bug could be exploited to severely disrupt the Bitcoin
  @p{brk} network we consider this a critical vulnerability, and encourage
  @p{brk} everybody to upgrade to the latest version: 0.6.2. @p{»»}

  @p{««}Backports for older releases (0.5.5 and 0.4.6) are also available
  if @p{brk} you cannot upgrade to version 0.6.2. @p{»»}

  @p{««}Full technical details are being withheld to give people the
  @p{brk} opportunity to upgrade. @p{»»}

  @p{««}Thanks to Forrest Voight for discovering and reporting the
  vulnerability. @p{»»}

  @p{««} Questions that might be frequently asked: @p{»»}

  @p{««}How would I know if I am the victim of this attack? @p{»»}

  @p{««}Your bitcoin process would stop processing blocks and would have a
  @p{brk} different block count from the rest of the network (you can see
  the @p{brk} current block count at websites like blockexplorer.com or
  @p{brk} blockchain.info). Eventually it would display the message: @p{»»}

  @p{««}"WARNING: Displayed transactions may not be correct! You may need
  to @p{brk} upgrade, or other nodes may need to upgrade." @p{»»}

  @p{««}(note that this message is displayed whenever your bitcoin process
  @p{brk} detects that the rest of the network seems to have a different
  @p{brk} block count, which can happen for several reasons unrelated to
  @p{brk} this vulnerability). @p{»»}

  @p{««} Could this bug be used to steal my wallet? @p{»»}

  @p{««}No. @p{»»}

  @p{««} Could this bug be used to install malware on my system? @p{»»}

  @p{««}No. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1609}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-15 12:42:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=73648.msg901639@s{hash}msg901639
@section 3 {tx}

  @p{««}Bitcoind doesn't run on ppc@p{--} and minimum supported osx version
  is 10.5. @p{»»}

  @p{««}And Armory depends on bitcoind, right?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1610}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-15 16:58:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=81677.msg901975@s{hash}msg901975
@section 3 {tx}

  @p{««}What Pieter said. BIPs are intended to make it easier for different
  implementations of Bitcoin to inter-operate with each other. The
  existing network protocol is just one piece of that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1611}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-18 01:20:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=82213.msg906833@s{hash}msg906833
@section 3 {tx}

  @s{quotedtext}

  @p{««}Gather (or generate) 3 bitcoin addresses, on whichever machines
  will be participating, using getnewaddress or getaccountaddress RPC
  commands (or copy and paste from the GUI). @p{»»}

  @p{««}Get their public keys using the validateaddress RPC command 3
  times. @p{»»}

  @p{««}Then create a 2-of-3 multisig address using addmultisigaddress;
  e.g. @p{»»}

  @s{quotedtext}

  @p{««}addmultisigaddress returns the multisignature address. Be a little
  careful, the public keys are raw hexadecimal and don't contain checksums
  like bitcoin addresses do. @p{»»}

  @p{««}You can then send funds into that 2-of-3 transaction using the
  normal sendtoaddress/sendmany RPC commands, or the GUI (or anything
  that's been updated to recognize multisig addresses). @p{»»}

  @p{««}That will create a multi signature transaction. @p{»»}

  @p{««}If you want to then SPEND the funds sent in that 2-of-3
  transaction... that isn't implemented yet (well, if bitcoin has all 3
  private keys in it's wallet then the funds will show up in the wallet's
  total balance and it may be selected to be spent like any other funds
  received by the wallet). "We" need to implement RPC calls to implement
  @p{(link}BIP 10@p{link)} or something like it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1612}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-18 02:14:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=82182.msg906929@s{hash}msg906929
@section 3 {tx}

  @p{««}The Bitcoin Faucet's wallet was stolen a couple of months ago:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1613}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-21 00:25:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=82678.msg911544@s{hash}msg911544
@section 3 {tx}

  @s{quotedtext}

  @p{««}No. Bitcoin connections are TCP, so you can't forge the IP address.
  @p{»»}

  @p{««}I've also implemented denial-of-service checks that automatically
  ban misbehaving peers to make network disruption attacks more difficult.
  Trying to anticipate future DoS attacks is hidden engineering work that
  you will never notice if we get it right.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1614}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-22 13:18:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=82213.msg914440@s{hash}msg914440
@section 3 {tx}

  @s{quotedtext}

  @p{««}Works in a Terminal on my Mac, returns: @s{quotedtext}

  @p{««}... which validates as: @s{quotedtext}

  @p{««}I don't know enough about Windows CLI quoting rules to get
  ("...","...","...") passed un-modified to bitcoind.exe. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1615}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-24 15:42:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80521.msg919375@s{hash}msg919375
@section 3 {tx}

  @p{««}Your unit tests look like they'll miss lots of edge cases. @p{»»}

  @p{««}I've been working on cross-implementation unit tests for Script,
  and am actually working on more tests today (and am working on a testnet
  reset that will embed the "should validate" tests into the testnet block
  chain). @p{»»}

  @p{««}JSON format tests are here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}(read by @s{(link)} )@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1616}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-25 01:15:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80521.msg920503@s{hash}msg920503
@section 3 {tx}

  @s{quotedtext}

  @p{««} The format is a list of pairs, where the first item is the
  scriptSig required to spend and the second is the scriptPubKey. The
  third item is ignored (useful for comments). @p{»»}

  @p{««}script_valid.json contains only valid scriptSig/scriptPubKey pairs.
  @p{brk} script_invalid.json contains only invalid scriptSig/scriptPubKey
  pairs. @p{»»}

  @p{««}valid/invalid are defined by the rules of transaction validation,
  and the unit test actually constructs transactions and runs the
  verification routine on them to make sure that they succeed or fail, as
  expected. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1617}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-30 17:12:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83645.msg930774@s{hash}msg930774
@section 3 {tx}

  @p{««}So code up a prototype: @p{»»}

  @p{(li}  Implement code that computes and publishes 'balance blocks' and
  'balance block hashes'. Convince a couple people with extra download
  bandwidth to run it.  @p{li)}

    @p{(li}@p{(li} Modify one of the bitcoin implementations to download
    the latest 'balance block' from some trusted place at startup, and use
    it if transactions/blocks can't be found in the traditional block
    database. @p{li)} @p{(li} Extra credit/paranoia : query a couple of
    trusted places for the balance block hash, and make sure it matches
    the hash you got. @p{li)} @p{(li} OR: randomly spot-check the balance
    block by requesting blocks in the traditional way, and make sure the
    balance block doesn't list any outputs as unspent that are actually
    spent. @p{li)}

  @p{««}You don't want bitcoin address balances, there are no addresses way
  down deep inside. You need to know which transaction outputs have not
  yet been spent, and the value of those outputs. @p{»»}

  @p{««}I'm not excited about this proposal, because I think it is solving
  a problem that doesn't need solving yet, and my priorities for bitcoin
  continue to be wallet security and network stability, not making it
  quicker for newbie solo miners to get a full blockchain so they can
  start validating transactions/blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1618}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-30 17:23:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83751.msg930800@s{hash}msg930800
@section 3 {tx}

  @p{««}Chaining not-yet-signed transactions is impossible because
  transaction inputs are identified by the previous transaction's hash,
  and the transaction's hash includes everything about the transaction,
  including the signatures. @p{»»}

  @p{««}A multisignature transaction taking funds from @s{hash}1 and paying them
  to @s{hash}4 that requires signatures from @s{hash}1, @s{hash}2, and @s{hash}3 should accomplish the
  same thing, though. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1619}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-30 17:43:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84247.msg930857@s{hash}msg930857
@section 3 {tx}

  @s{quotedtext}

  @p{««} And in two years maybe anybody who can afford to buy an
  asic-mining-space-heater for their house can mine. And in ten years
  maybe new houses will come pre-equipped with
  asic-mining-baseboard-electric-heaters. @p{»»}

  @p{««}Or maybe not. Nobody knows what is going to happen, which is why I
  keep repeating BITCOIN IS AN EXPERIMENT IN PROGRESS. If you can't handle
  uncertainty and the very real possibility that the experiment will fail,
  then don't get involved (but don't come back whining that you missed out
  if the experiment turns out to be a huge success). @p{»»}

  @s{quotedtext}

  @p{««}No, I don't think it is a problem, any more than the relatively
  small number of "backbone" routers are a problem for the Internet. The
  bitcoin network is evolving in roughly the direction I expected it would
  (lots of lightweight clients connecting to a smaller number of
  heavyweight "backbone" nodes). @p{»»}

  @p{««}All of the incentives are for merchants, exchanges, and big mining
  pools to accept lots of connections, relay only valid transactions and
  blocks, and be as DoS-resistant as they can afford. Merchants and
  exchanges want transactions to be validated quickly, the big mining
  pools want their payouts to be processed quickly and want their blocks
  propagated quickly, and they all want to be reliable. The big exchanges
  and mining pools have ALREADY implemented DDoS countermeasures because
  they have ALREADY been attacked. And the network keeps chugging away,
  processing transactions.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1620}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-30 18:59:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83645.msg931045@s{hash}msg931045
@section 3 {tx}

  @p{««}etotheipi: @p{»»}

  @p{««}Sorry, I was responding to the original proposal, not yours, I
  should have made that clear. @p{»»}

  @p{««}Better protocol support for lightweight clients is a Good Idea.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1621}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-31 00:33:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83966.msg931842@s{hash}msg931842
@section 3 {tx}

  @p{««}There will be 2.1 quadrillion satoshis. @p{»»}

  @p{««}There are approximately 770 trillion pennies in the @p{(link}US M2
  money supply@p{link)}. @p{»»}

  @p{««}We've got a VERY VERY long way to go before bitcoins are as popular
  as dollars, and there are much higher priority things to work on right
  now than adding more divisibility for a problem that is pretty likely to
  never actually be a problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1622}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-31 13:21:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=82213.msg932627@s{hash}msg932627
@section 3 {tx}

  @s{quotedtext}

  @p{««}Use one of the send commands to send to the multisig address
  several times and you will create several multisig transactions. @p{»»}

  @p{««}addmultisigaddress does not create a transaction, it just creates a
  place for future transactions to go. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1623}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-05-31 14:03:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84247.msg932675@s{hash}msg932675
@section 3 {tx}

  @p{««}Sipa has been busy implementing IPv6 support and much better
  support for running bitcoin as a Tor hidden service. Both of those
  should help make the network more robust and resistant to attack. If a
  lot of people decide to run only inside Tor then it will look like even
  fewer nodes are listening, though. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1624}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-01 17:39:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84704.msg935342@s{hash}msg935342
@section 3 {tx}

  @p{««}Once. @p{»»}

  @p{««}(it is actually once every couple of months, but that's a secret
  and might change so don't tell anybody that)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1625}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-01 18:02:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84645.msg935380@s{hash}msg935380
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ummm.... @p{»»}

  @p{««}When you run something like: Code: bitcoind getinfo @p{brk} ...
  bitcoind creates a network connection to localhost:rpcport and talks to
  the running bitcoind process via the JSON-RPC protocol. @p{»»}

  @p{««}So it doesn't matter what user the Code: bitcoind getinfo process
  is running as, what matters is securing access to the JSON-RPC network
  port, keeping the rpcpassword a secret, and preventing attackers from
  getting in and copying wallet.dat. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1626}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-01 18:10:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83209.msg935388@s{hash}msg935388
@section 3 {tx}

  @p{««}I love you guys, and hope you're being wildly successful... but:
  @p{»»}

  @p{««}Plugging in "Deposit $200, get $192" for a cash deposit and then
  finding out I'll actually have to bring $204.95 or $201.58 because of an
  extra third-party processing fee feels like bait-and-switch to me. Don't
  you know in advance how much the payment processors will charge? Does it
  vary based on location or something? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1627}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-02 14:16:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84867.msg936831@s{hash}msg936831
@section 3 {tx}

  @p{««}How would you use a 'getaddressbalance'? What are you trying to do?
  @p{»»}

  @p{««}Start with an empty wallet. I send you 100 BTC to address 'foo'.
  Then you send somebody else 1 BTC. @p{»»}

  @p{««}Internally, a new change address with @p{(so}49@p{so)} (edit: 99)
  bitcoins is created, so getaddressbalance 'foo' would return zero. Would
  that ever be the right answer? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1628}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-02 14:26:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84867.msg936840@s{hash}msg936840
@section 3 {tx}

  @s{quotedtext}

  @p{««}I should lie and say I'm feeling extra generous to miners this
  morning and wanted to give them an imaginary 50 BTC fee... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1629}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-03 18:28:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=84984.msg938775@s{hash}msg938775
@section 3 {tx}

  @p{««}I'd love to see somebody resurrect the Visual C++ makefile and
  build instructions (and let us know if we've accidentally added and
  gcc-specific code), so Windows developers didn't have to spin up a VM
  and cross-compile everything. @p{»»}

  @p{««}As to why your builds are different: no idea, but you can look at
  the file-by-file checksums in the bitcoin-build.assert file to see
  exactly what is different. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1630}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-04 12:57:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85222.msg940086@s{hash}msg940086
@section 3 {tx}

  @p{««}I think consolidating everything under one domain is dangerous and
  against the decentralized nature of the Bitcoin project. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1631}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-04 13:16:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85191.msg940114@s{hash}msg940114
@section 3 {tx}

  @p{««}I just got stuck@p{--} looks like somebody is serving up the
  testnet2 blockchain to testnet3 nodes that connect to them (that's what
  is causing the 'nBits below minimum work' message). @p{»»}

  @p{««}Re-running to connect to a real testnet3 node is getting me the
  correct blockchain (with 6,905 blocks). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1632}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-04 15:17:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80521.msg940276@s{hash}msg940276
@section 3 {tx}

  @s{quotedtext}

  @p{««} Signatures are BER-encoded data structures, and can be an
  arbitrary number of bytes (if they're DER-encoded, which is the strict
  subset of BER encoding, then they're 70-something bytes). @p{»»}

  @p{««}Public keys are either 33 or 65 bytes (not counting the "push the
  next N bytes onto the stack" CSCript opcode). @p{»»}

  @p{««}I've got to say you make me nervous; you seem to be following a
  "make it work for a couple of test cases then move on" style of
  development, which is a bad way to create a secure, robust codebase.
  @p{»»}

  @p{««}PS: I sympathize with you RE: OpenSSL's lack of documentation....
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1633}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-04 16:10:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85191.msg940413@s{hash}msg940413
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bitcoin-Qt ? Sounds like a bug in the "estimate how many blocks
  there are based on what your peers tell you" bug. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1634}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-04 19:21:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85191.msg940872@s{hash}msg940872
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes... but having peers with a completely different block chain
  from you connect is a good way to shake out obscure bugs. Like
  Bitcoin-Qt's "how many blocks are in the valid chain" code getting
  fooled... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1635}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-06 17:36:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85645.msg945081@s{hash}msg945081
@section 3 {tx}

  @p{««}RE: the 100/120 difference: @p{»»}

  @p{««}Check my work, but I think this is the scenario where it would
  matter and cause headaches: @p{»»}

  @p{««}You generate a block 100 blocks before a difficulty adjustment.
  @p{»»}

  @p{««}Then you spend the coinbase exactly 100 blocks later, in a block in
  the next difficulty period. And, let's say, whoever you send the
  bitcoins to spends that transaction again immediately. @p{»»}

  @p{««}Now imagine a really wacky scenario where you're reorganized onto a
  shorter-but-has-more-difficulty block chain. That could happen if you
  were disconnected from the main bitcoin network for a while. @p{»»}

  @p{««}Your coinbase-spend transaction and any transactions that depend on
  it can't be included in the main chain because they're immature, so they
  get dropped from everybody's memory pool as "trying to spend an immature
  coinbase." I'm not sure what then happens; I think you'd eventually
  retransmit them and get them into the main chain, but that could take a
  while. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1636}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-08 21:19:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86326.msg950044@s{hash}msg950044
@section 3 {tx}

  @p{««}I actually created and spent some "input from wallet a", "input
  from wallet b" private testnet transactions earlier this week (I'm
  working on some lower-level RPC commands for bitcoind @p{--} see
  @s{(link)} for the half-baked spec). @p{»»}

  @p{««}Somebody could build a transaction-combining service on top of
  those low-level RPC commands, although I suspect to be really resistant
  to sophisticated network analysis doing "one or more inputs from A in,
  one or more from B in, ApayToSomebody Achange BpayToSomebodyElse Bchange
  out" won't help much. There is a lot of prior work on "mix networks" and
  maintaining anonymity, and the only thing I know about it is that it is
  a hard problem to get right. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1637}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-11 17:55:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=83751.msg955499@s{hash}msg955499
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've been switching back and forth between writing a spec for it (
  @s{(link)} ), implementing it ( @s{(link)} ), writing up a test plan (
  @s{(link)} ) and testing. @p{»»}

  @p{««}My goal is to get all that done by the end of this week and have it
  in the 0.7 release. But lots of things could make it take longer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1638}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-11 18:39:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=85832.msg955594@s{hash}msg955594
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, I don't have a prototype. @p{»»}

  @p{««}The hardware is real and very cool, but they've got a lot of work
  to do on software and user interface and manufacturing process and
  marketing and distribution and.... . Expect the design to change before
  you can actually buy one. And like all really innovative projects (and
  to quote the MythBusters) "Failure is always an option." @p{»»}

  @p{««}Answering detailed questions about exactly how it works right now
  would be a waste of time, because I think before it ships most of the
  answers will be different. The meeting in Vienna was for bitcoincard to
  get early feedback on whether or not they're headed in a good direction.
  @p{»»}

  @p{««}RE: why would you want a bitcoincard versus just using your
  cellphone: I personally think you'll want both; I'm trying to convince
  them that the bitcoincard could be a perfect "second device" for
  multisignature transactions. Cell phone viruses and trojans and malware
  will be the next big wave of security vulnerabilities. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1639}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-11 18:48:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86990.msg955616@s{hash}msg955616
@section 3 {tx}

  @s{quotedtext}

  @p{««}You just poked one of my pet peeves: the Y-axis on your Euro chart
  doesn't start at zero, so you're exaggerating it's volatility. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1640}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-11 21:59:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87045.msg956133@s{hash}msg956133
@section 3 {tx}

  @s{quotedtext}

  @p{««}Where did you read that bitcoin is supposed to be anonymous? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1641}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-11 22:49:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87045.msg956238@s{hash}msg956238
@section 3 {tx}

  @p{««}Once upon a time bitcoin.org called Bitcoin "anonymous" but that
  was a mistake, and for at least two years "we" (core developers) have
  tried to be careful to say that, at best, Bitcoin is pseudanonymous.
  @p{»»}

  @p{««}I tell reporters that Bitcoin is more private than using any other
  online payment method, but less private than cash (unless you know a lot
  about how it works under the covers and jump through several hoops to
  keep your identity secret). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1642}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-12 12:48:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86292.msg957372@s{hash}msg957372
@section 3 {tx}

  @p{««}You're a crazy-man. Crazy in a good way... ever do any APL
  programming? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1643}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-12 12:56:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86947.msg957380@s{hash}msg957380
@section 3 {tx}

  @p{««}Relevant discussion here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1644}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-14 13:31:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87545.msg962287@s{hash}msg962287
@section 3 {tx}

  @p{««}Cross-posting from the bitcoin-development list: @p{»»}

  @p{««}I submitted a pull request yesterday that implements low-level
  "raw" transaction, and am looking for feedback on the API and help with
  trying to test/break it. @p{»»}

  @p{««}Design doc: @s{(link)} @p{brk} Pull request: @s{(link)} @p{brk}
  Test plan: @s{(link)} @p{»»}

  @p{««}Playing around with this API on the command line I'm pretty happy
  with the level of abstraction and the way it interacts with existing RPC
  commands; for example, "createrawtx" is just like "sendmany" in the way
  outputs are specified. @p{»»}

  @p{««}The signrawtx method is the key new method; it takes a raw
  transaction, signs as many inputs as it can, and returns the same raw
  transaction with signatures. Typical usage would be: @p{»»}

  @p{««}Funds are sitting in a multisignature transaction output, and it is
  time to gather signatures and spend them. @p{»»}

  @p{««}Assumption: you know the multisignature transaction's (txid,
  outputNumber, amount). @p{»»}

  @p{««}Create a raw transaction to spend, using createrawtx. @p{brk} Use
  signrawtx to add your signatures (after unlocking the wallet, if
  necessary). @p{brk} Give the transaction to the other person(s) to sign.
  @p{brk} You or they submit the transaction to the network using
  sendrawtx. @p{brk} I don't imagine anybody but very-early-adopters or
  ultra-geeks will do this by calling these RPC methods at a command-line.
  They are really intended for people writing services on top of bitcoind.
  The service should be careful to include an appropriate transaction fee,
  or the sendrawtx method is likely to fail. @p{»»}

  @p{««}I've been asked a couple of times: why doesn't signrawtx handle the
  BIP 0010 (@s{(link)}) transaction format? @p{»»}

  @p{««}I considered parsing/writing BIP 10 format for raw transactions,
  but decided that reading/writing BIP 10 format should happen at a higher
  level and not in the low-level RPC calls. So 'raw transactions' are
  simply hex-encoded into JSON strings, and encoding/decoding them is just
  a couple of lines of already-written-and-debugged code. @p{»»}

  @p{««}Here is the help output and example use for all the new RPC calls: @p{»»}

  @p{(li}listunspent (minconf=1) (maxconf=999999) @p{brk} Returns array of
  unspent transaction outputs with between minconf and maxconf
  (inclusive) confirmations. Returns an array of 4-element arrays,
  each of which is: (transaction id, output, amount,
  confirmations) @p{li)}

  @p{««}E.g: @s{code} @p{»»}

  @p{(li}getrawtx @p{lt}txid@s{gt} @p{brk} Returns hexadecimal-encoded,
  serialized transaction data for @p{lt}txid@s{gt}. Returns an
  error if @p{lt}txid@s{gt} is unknown. @p{li)}

  @p{««}E.g.: @s{code} @p{»»}

  @p{««} createrawtx (("txid",n),...) (address:amount,...) @p{brk} Create a
  transaction spending given inputs @p{brk} (array of (hex transaction id,
  output number) pairs), sending to given address(es). 
  Returns the same information as gettransaction, plus an extra
  "rawtx" key with the hex-encoded transaction. Note that the
  transaction's inputs are not signed, and it is not stored in the
  wallet or transmitted to the network. @p{»»}

  @p{««}E.g.: @s{code} @p{»»}

  @p{(li}signrawtx @p{lt}hex string@s{gt}
  (@p{lt}prevtx1@s{gt},@p{lt}prevtx2@s{gt}...) @p{brk} Sign inputs for raw
  transaction (serialized, hex-encoded). Second argument is an
  array of raw previous transactions that this transaction depends
  on but are not yet in the blockchain. Returns json object with
  keys: @p{li)}

    @p{(li}rawtx : raw transaction with signature(s) (hex-encoded string) @p{li)}

    @p{(li}complete : 1 if transaction has a complete set of signature (0 if not) @p{li)}

  @p{««}E.g.: @s{code} @p{»»}

  @p{««}sendrawtx @p{lt}hex string@s{gt} @p{brk} Submits raw transaction
  (serialized, hex-encoded) to local node and network.@p{»»}

  @p{««} E.g.: @s{code} @p{»»}

  @p{««}(Rejected because it doesn't have all required signatures, if it
  was accepted it would return the transaction id) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1645}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-15 15:36:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87660.msg965178@s{hash}msg965178
@section 3 {tx}

  @p{««}This is why I think the so-called "stable" backports are a bad
  idea. I want people to spend time finding and fixing bugs in 0.6.2, and
  I want people to realize that the core developers are not supporting
  older releases. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1646}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-16 00:53:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87768.msg966421@s{hash}msg966421
@section 3 {tx}

  @p{««}The 0.7 release will include an optimization that should help a lot
  (transaction signature cache @p{--} prior releases checked signatures
  when the transaction was first seen, and then checked again when a new
  block was received, it makes processing new blocks much faster). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1647}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-17 16:12:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86679.msg969723@s{hash}msg969723
@section 3 {tx}

  @s{quotedtext}

  @p{««}The 0.7 release optimizes transaction validation, so most
  transactions that were validated when broadcast/relayed across the
  network don't have to be re-validated when they're included in a block.
  That will speed up block verification/relaying a lot. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1648}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-17 16:19:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=23768.msg969737@s{hash}msg969737
@section 3 {tx}

  @s{quotedtext}

  @p{««}Luke is guessing it is SatoshiDice, it might just be a run of bad
  luck. @p{»»}

  @p{««}Or it might be a side effect of Eligius accepting non-standard
  transactions. @p{»»}

  @p{««}Does Eligius include transactions that have not been
  transmitted/relayed to the rest of the network? If so, it might be a
  side effect of that (and if that isn't a side effect now, it might be in
  the future if Eligius blocks take longer to verify as other nodes need
  to fetch transaction inputs from disk, instead of already having them in
  cache memory like transactions that ARE transmitted/relayed). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1649}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-18 13:41:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88325.msg971679@s{hash}msg971679
@section 3 {tx}

  @p{««}I gathered data on transaction first-confirmation times this
  weekend: @p{»»}

  @p{««} @s{(link)} @p{»»}

  @p{««}Each line in the file (except the first one) represents one
  transaction. Each column is: @p{»»}

  @p{««}Number of seconds the transaction spent in the memory pool. @p{»»}

  @p{««}Size, in bytes, of the transaction. @p{»»}

  @p{««}Fees attached to the transaction (in satoshis). @p{»»}

  @p{««}Priority (floating-point number) of the transaction when it first
  entered the memory pool. Priority 0.0 transactions have inputs that
  aren't yet confirmed. @p{»»}

  @p{««}Last column is "1" if the transaction exited the memory pool
  normally, by being included in the a block, or "0" if the transaction
  was still in the memory pool when I shut down bitcoind. @p{»»}

  @p{««}I haven't really analyzed it yet (feel free to help if you're a
  data geek); I plan on testing some algorithms for suggesting a
  reasonable fee if you want your transaction to get confirmed quickly,
  and suggesting an estimate of how long you'll have to wait if you don't
  attach any fee at all. @p{»»}

  @p{««}But it look like 35% of transactions this past weekend got into a
  block within 10 minutes, and 87% got into a block within one hour. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1650}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-19 23:52:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88613.msg975967@s{hash}msg975967
@section 3 {tx}

  @p{««}The RPC and GUI won't let you spend 0-confirmation transactions
  unless they are 'change' outputs from yourself. @p{»»}

  @p{««}If you REALLY want to shoot yourself in the foot, I've got a pull
  request for the 0.7 release that adds 'raw transaction' RPC commands
  that will let you do all sorts of dangerous things, including
  @p{(so}counting your chickens before they've hatched@p{so)} spending
  unconfirmed-from-somewhere-else inputs. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1651}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-20 00:14:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88302.msg976011@s{hash}msg976011
@section 3 {tx}

  @s{quotedtext}

  @p{««}Chain proof-of-work is calculated based on the hash target, so if
  you get another block at the same height there is no benefit to keeping
  the one with "the smaller hash". @p{»»}

  @p{««}Maybe if you receive a second block solution, keeping the block
  that removes the most transactions from the memory pool would be the
  right "good for the entire ecosystem" policy. That way even if small
  blocks propagate slightly faster that might be offset if a larger,
  slower block was found. (but making new-block-flooding independent of
  the size of the block is an even better solution, and that shouldn't be
  too hard to implement) @p{»»}

  @p{««}Creating a semi-trusted backbone of connections to other
  pools/miners so your new blocks propagate quickly is a good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1652}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-20 16:54:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88734.msg977560@s{hash}msg977560
@section 3 {tx}

  @p{««}We're releasing 0.6.3 to fix two important issues (a serious
  potential denial-of-service attack, and to improve new-block propagation
  times for blocks containing lots of transactions). @p{»»}

  @p{««}If you can, please help do some sanity testing@p{--} shutdown
  bitcoin, then download, install, and run 0.6.3 and let us know "works
  nicely for me running on 64-bit Ubuntu 10.04" by posting a quick reply
  to this thread. @p{»»}

  @p{««}Release notes: @p{»»}

  @p{««}Bitcoin version 0.6.3rc1 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix release, with no new features. @p{»»}

  @p{««}CHANGE SUMMARY @p{»»}

  @p{««}Fixed a serious denial-of-service attack that could cause the
  @p{brk} bitcoin process to become unresponsive. Thanks to Sergio Lerner
  @p{brk} for finding and responsibly reporting the problem.
  (CVE-2012-3789) @p{»»}

  @p{««}Optimized the process of checking transaction signatures, to
  @p{brk} speed up processing of new block messages and make propagating
  @p{brk} blocks across the network faster. @p{»»}

  @p{««}Fixed an obscure bug that could cause the bitcoin process to get
  @p{brk} stuck on an invalid block-chain, if the invalid chain was
  @p{brk} hundreds of blocks long. @p{»»}

  @p{««}Bitcoin-Qt no longer automatically selects the first address
  @p{brk} in the address book (Issue @s{hash}1384). @p{»»}

  @p{««}Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac. @p{»»}

  @p{««}Added a block checkpoint at block 185,333 to speed up initial
  @p{brk} blockchain download. @p{»»}

  @p{««} Thanks to everybody who contributed to this release:  @p{»»}

  @p{««}Chris Moore @p{brk} Christian von Roques @p{brk} Fordy @p{brk}
  Gavin Andresen @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Matt
  Corallo @p{brk} Michael Hendricks @p{brk} Peter Todd @p{brk} Philip
  Kaufmann @p{brk} Pieter Wuille @p{brk} R E Broadley @p{brk} Sergio
  Lerner @p{brk} Wladimir J. van der Laan @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1653}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-20 21:15:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88734.msg978187@s{hash}msg978187
@section 3 {tx}

  @p{««}Before you copy the blk* files, you must run with the -detachdb
  option and make sure you shutdown bitcoin and wait for it to exit
  completely. With 0.6.2, we change the default from "take a long time to
  shut down, but leave standalone .dat files" to "shutdown quickly, but
  leave .dat files that are tied to the database/log.* files". @p{»»}

  @p{««}Too many ordinary users were quitting bitcoin and then immediately
  powering off their systems, leaving the database in a bad state. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1654}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-20 23:45:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88783.msg978541@s{hash}msg978541
@section 3 {tx}

  @p{««}The things on my "good enough to be called 1.0" list are: @p{»»}

  @p{(li}  easy enough for my grandma to use  @p{li)}

    @p{(li}@p{(li} secure enough that it'd be hard for my grandma to lose
    her bitcoins, even if her computer is infected by 11 bitcoin-stealing
    trojans and then catches fire and explodes. @p{li)} @p{(li} past the
    December block-reward-drops-to-25 @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1655}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-21 00:12:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88783.msg978591@s{hash}msg978591
@section 3 {tx}

  @p{««}I'll buy my grandma a terabyte drive for Christmas. @p{»»}

  @p{««}No, seriously, a better startup experience is part of "easy to use"
  @p{--} waiting hours for the blockchain to sync sucks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1656}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-21 13:49:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88892.msg979718@s{hash}msg979718
@section 3 {tx}

  @p{««}In the 0.6.3 thread Graet asks a good question: what's do we mean
  by "critical" versus "serious" vulnerability? @p{»»}

  @p{««}Here's what those terms mean to me. All examples are hypothetical:
  @p{»»}

  @p{««}A critical vulnerability is one that will have disastrous
  consequences if it is exploited. Examples might be a remote code
  exploit, a bug that somebody could use to take down the entire bitcoin
  network, or a bug that could be exploited to steal your entire wallet.
  @p{»»}

  @p{««}A serious vulnerability is one that will have serious consequences
  if it is exploited. Examples might be a bug that can be triggered by
  network traffic and will cause the software to stop working or a bug
  that could be exploited to misdirect your next bitcoin transaction so it
  goes to an attacker instead of the intended recipient. @p{»»}

  @p{««}The 0.6.3 denial-of-service problem I consider "serious" @p{--} an
  attacker who figures out exactly what the vulnerability is (we haven't
  disclosed that yet) can make bitcoind or Bitcoin-Qt stop processing
  transactions. @p{»»}

  @p{««}Then there are run-of-the-mill vulnerabilities; things like Sybil
  attacks that require an attacker to round up hundreds or thousands of
  machines, or denial-of-service attacks that require that the attacker be
  able to send the victim gigabytes of network traffic. Dealing with these
  often doesn't even merit a mention in the release notes, because they
  affect so few people and require an attacker willing to spend a fair bit
  of money and/or effort just to be annoying. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1657}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-21 14:29:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88491.msg979807@s{hash}msg979807
@section 3 {tx}

  @p{««}I usually answer with: @p{»»}

  @p{««}Why do screwdrivers have value? What backs the value of a
  screwdriver? @p{brk} Because they're useful and it takes effort to
  create them. @p{»»}

  @p{««}Bitcoin has value for the same reasons.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1658}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-21 14:31:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88661.msg979811@s{hash}msg979811
@section 3 {tx}

  @p{««}Anybody know where I can buy an "I am a Space Lizard" T-shirt for
  bitcoin?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1659}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-22 14:00:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=88892.msg982034@s{hash}msg982034
@section 3 {tx}

  @p{««}I think "1 2 3 4" is bad. 4 is more than 1, so a level 4
  vulnerability is worse, right? @p{»»}

  @p{««}I still like critical/serious/other. More gradations than that and
  I think we'll just waste time arguing over "is this a level 3
  vulnerability? level 4? ok, let's make it a pi vulnerability
  (3.1415...)" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1660}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-25 00:35:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89725.msg987757@s{hash}msg987757
@section 3 {tx}

  @p{««}My work on the @p{(link}'raw transaction'@p{link)} API has me
  thinking hard about the gettransaction/getblock RPC calls. I want it to
  be easy for the information returned by those calls to be used by the
  new createrawtx/etc API calls. @p{»»}

  @p{««}So: in version 0.6.3 and earlier, gettransaction would only return
  information about transactions in your wallet, and would not return all
  of the information about the transaction. @p{»»}

  @p{««}A month or two ago Pieter and Luke wrote code to modify
  gettransaction/getblock to return information about any transaction in
  the blockchain and a new 'decompositions' Object argument was added to
  those RPC calls that would let you specify 5 different ways to get
  information about transaction inputs and outputs (no/hash/hex/asm/obj).
  So you might do: @p{»»}

  @p{««}@s{code} @p{brk} I think 5 different ways of getting (or not
  getting if you specify 'no') the information is 4 too many, so I'm
  modifying the code as follows: @p{»»}

    @p{(li}getblock doesn't change from version 0.6; it returns a list of
    transaction id's in a "tx" Array.@p{li)}

    @p{(li}gettransaction gets an extra boolean argument that defaults to
    0 (false). If non-zero is passed, then it is verbose and outputs
    information about the transaction inputs and outputs in all the
    different formats (same as what decomposition "obj" does).@p{li)}

    @p{(li}for compatibility with the 'raw transaction' API calls,
  gettransaction always return the full serialized-hex-encoded transaction
  data as a new "rawtx" field.@p{li)} The thinking is either RPC users
  will want minimal information quickly, or will want full information and
  won't care much if they get extra information. If you want full
  information as quickly as possible, then you should write code to decode
  the "rawtx" array yourself. @p{»»}

  @p{««}This does mean getting full information for every transaction in a
  block means more than one RPC call, but Jeff has a pull request for
  JSON-2.0 "batch" calls, so getting full information about every
  transaction in a block will be just two RPC round-trips (one getblock,
  then one batch with a bunch of gettransaction calls in it). @p{»»}

  @p{««}And to be clear: these changes are meant to be 100%
  backwards-compatible with getblock/gettransaction in version 0.6.3 and
  earlier. We're talking about extra arguments and extra information in
  the returned JSON objects. @p{»»}

  @p{««} @p{hrule} Example output for a complicated multisignature testnet
  transaction: @p{»»}

  @p{««}Short, in-wallet transaction: @p{»»} 
  
  @s{code}

  @p{««}Verbose: @p{»»}

  @s{code}

  @p{««} @p{hrule} The only feature that bothers me is reporting
  'addresses/type' for transaction inputs. It bothers me for two reasons:
  @p{»»}

  @p{(li}1) It is expensive to fetch that data, because it means finding the
  previous transaction in the blockchain and fetching it from disk. It
  violates the principle that "a feature shouldn't cost you anything if
  you're not using it." @p{li)}

  @p{(li}2) If "we" implement spent-input pruning (Pieter has some fantastic
  early results) that data might not exist. @p{li)}

  @p{««}I think it would be better to remove the 'addresses/type'
  information from gettransaction output, so gettransaction never has to
  lookup previous transactions. @p{»»}

  @p{««}If you care about the previous transaction, then you would have to
  call gettransaction again, using vin.prevout.hash to look them up (and,
  again, using the JSON-2.0 'batch' feature to lookup all the prior
  transactions in one RPC roundtrip). @p{»»}

  @p{««}If/when transaction pruning happens then the semantics are clear:
  that gettransaction would return an error if the prior transaction was
  pruned.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1661}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-25 00:45:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24784.msg987771@s{hash}msg987771
@section 3 {tx}

  @s{quotedtext}

  @p{««}See the @p{(link}raw transaction API@p{link)} I've been working on,
  and please help try to break it@p{--} it needs more testing. @p{»»}

  @p{««}The main motivation is to move forward with multisignature
  transactions, but it also lets you have complete control over the
  source(s) for a transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1662}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-25 01:19:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89728.msg987822@s{hash}msg987822
@section 3 {tx}

  @p{««}When I tell people I work on Bitcoin full-time, a somewhat common
  reaction is "Really? I thought Bitcoin was finished, what do you work
  on?" @p{»»}

  @p{««}I spend half my development time working on new stuff (or testing
  new stuff that other people have submitted), but the other half I spend
  trying to anticipate problems or reacting to problems that are reported.
  That work tends to be unseen, partly because we want to keep problems
  quiet while we fix them and partly because quietly anticipating/fixing
  problems minimizes the 'lulz' that attackers might enjoy if every
  single-node-DoS attack caused us to run around like chickens with our
  heads cut off. @p{»»}

  @p{««}Anyway, good developers are hard to find, and one of the reasons
  I'm not thrilled by all of the AlternaCoins is because I'd rather a good
  developer help make Bitcoin better rather than spend their time with the
  busy-work of cross-porting the latest Bitcoin fixes to some other
  codebase. I would guess that some of the developers of the alternative
  chains underestimated the amount of work it takes to nurture them and
  keep them healthy. Maybe that will change when Bitcoin is truly mature
  and has dealt with another year or two or six of attacks and scaling
  issues... @p{»»}

  @p{««}I truly don't mean this to sound like a threat, but I think some of
  the blockchains that have been chugging along running on an ancient
  forked version of the Bitcoin codebase will be attacked; pretty soon
  we'll be fully disclosing the denial-of-service bugs that prompted the
  0.6.2/0.6.3 releases, and it is highly likely @p{(bf}somebody@p{bf)}
  will decide to play with exploit code on a vulnerable chain. @p{»»}

  @p{««}I wish people would find more constructive things to do with their
  time, but I wish I could fly and never get old like Peter Pan, too.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1663}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-25 15:22:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24784.msg989051@s{hash}msg989051
@section 3 {tx}

  @s{quotedtext}

  @p{««}Determining the "right" fees is a separate issue; see @s{(link)}
  for my current thinking. @p{»»}

  @p{««}The raw transaction API will let you create and try to send a
  transaction with as much or little fees as you like, but if you try to
  send a 20 kilobyte transaction with zero fees you shouldn't be surprised
  if nobody relays or mines it. @p{»»}

  @s{quotedtext}

  @p{««} If you use the raw transaction API then you're responsible for
  saying exactly where all of the outputs go. If you create a raw
  transaction with a 50 BTC input and a 2 BTC output then that is a
  no-change, 48 BTC fee transaction. If you don't intend the 48 BTC to go
  to miners, then you need to specify where the change goes by adding
  another output. @p{»»}

  @p{««}I suppose the RPC calls could have limits to try to keep you from
  shooting yourself in the foot, but anybody using the raw transaction API
  should be doing a lot of testing with worthless testnet coins and I'd
  rather not start playing the "lets write lots of code to try to prevent
  RPC-users from being dumb" game. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1664}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-25 17:52:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89877.msg989356@s{hash}msg989356
@section 3 {tx}

  @p{««}Bitcoin version 0.6.3 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix release, with no new features. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}CHANGE SUMMARY@p{»»}

  @p{««}Fixed a serious denial-of-service attack that could cause the
  @p{brk} bitcoin process to become unresponsive. Thanks to Sergio Lerner
  @p{brk} for finding and responsibly reporting the problem.
  (CVE-2012-3789) @p{»»}

  @p{««}Optimized the process of checking transaction signatures, to
  @p{brk} speed up processing of new block messages and make propagating
  @p{brk} blocks across the network faster. @p{»»}

  @p{««}Fixed an obscure bug that could cause the bitcoin process to get
  @p{brk} stuck on an invalid block-chain, if the invalid chain was
  @p{brk} hundreds of blocks long. @p{»»}

  @p{««}Bitcoin-Qt no longer automatically selects the first address
  @p{brk} in the address book (Issue @s{hash}1384). @p{»»}

  @p{««}Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac. @p{»»}

  @p{««}Added a block checkpoint at block 185,333 to speed up initial
  @p{brk} blockchain download. @p{»»}

  @p{««} Thanks to everybody who contributed to this release:@p{»»}

  @p{««}Chris Moore @p{brk} Christian von Roques @p{brk} Fordy @p{brk}
  Gavin Andresen @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Matt
  Corallo @p{brk} Michael Hendricks @p{brk} Peter Todd @p{brk} Philip
  Kaufmann @p{brk} Pieter Wuille @p{brk} R E Broadley @p{brk} Sergio
  Lerner @p{brk} Wladimir J. van der Laan @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1665}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-26 00:46:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89877.msg990386@s{hash}msg990386
@section 3 {tx}

  @s{quotedtext}

    @p{(li} 1. Make sure the SHA256SUMS.asc file hasn't been modified:
    @p{li)}

  @s{code}

  @p{««} 2. See what file you SHOULD have downloaded: @p{»»}

  @s{code}

  @p{««} 3. Make sure the file you downloaded is exactly the same: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1666}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-26 01:22:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89728.msg990457@s{hash}msg990457
@section 3 {tx}

  @p{««}Rereading my original post, I should make clear: the people I
  really have issues with are the people who think it is more fun to try
  to destroy something than to help build it. My comment about "I wish
  people would find more constructive things to do with their time" was
  not meant to be aimed not at AlternaCoin creators. @p{»»}

  @p{««}I agree that there are some benefits to the alternate chains
  existing; I just wonder if the costs of all the duplicate infrastructure
  (exchanges and pools and faucets and...) is worth the benefits. @p{»»}

  @p{««}RE: privately disclosing exploits to AlternaCoin developers: well,
  to be frank, I have no idea if most AlternaCoin developers can be
  trusted with sensitive exploit information or even who is currently
  supporting which chain. The danger would be somebody emailing me
  claiming to be the lead developer for FooCoin, I tell them about the
  vulnerability, and then they turn out to NOT be the lead FooCoin
  developer but an attacker. Or I tell FooCoin about the vulnerability and
  they decide to use it to launch an attack on their arch-enemy, BarCoin.
  @p{»»}

  @p{««}It is all drama and heartburn that I'd really rather not have
  (again, costs and benefits....)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1667}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-26 01:40:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89725.msg990497@s{hash}msg990497
@section 3 {tx}

  @p{««}More discussions in IRC today prompted further tweaks to this API:
  @p{»»}

  @p{««}"get any transaction, even transactions that aren't in your wallet"
  functionality will be moved from gettransaction to a new
  'getrawtransaction' API call, for two reasons: @p{brk} 1. It doesn't
  'feel' right to mix the high-level info with the nitty-gritty low-level
  detail. @p{brk} 2. We think there's a potential for security
  vulnerabilities if there are existing services that assume that
  'gettransaction txid' returns an error for any transaction not in the
  wallet (as it does in all previous releases). @p{»»}

  @p{««}So the new plan is to put the new functionality in a new RPC call:
  @p{»»}

  @p{««}getrawtransaction @p{lt}txid@s{gt} (verbose=0) : If verbose=0,
  returns a JSON string that is the hex-encoded, serialized transaction.
  That is the "machine readable, as concise as possible" use case. If
  verbose=1, returns a JSON object with all the nitty-gritty details, to
  cover all the other use cases. @p{»»}

  @p{««}Also, Jeff already has a pull request for JSON-2.0 "batch"
  functionality, so if you need information about all transactions in a
  block or all of a transaction's parent transactions you can get it with
  one RPC round-trip.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1668}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-26 15:26:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=79848.msg991549@s{hash}msg991549
@section 3 {tx}

  @p{««}Sounds kind of like youtipit, which is shutting down: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1669}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-26 22:15:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89725.msg992397@s{hash}msg992397
@section 3 {tx}

  @s{quotedtext}

  @p{««}Excellent point. I use python, which just works with different
  types in arrays, and C++/json_spirit, which also just works, but I can
  that other languages would be painful. @p{»»}

  @p{««}I'll go through the raw transactions API and will replace any
  "Array of different types" with "Array of Objects". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1670}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-27 15:31:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=90126.msg993977@s{hash}msg993977
@section 3 {tx}

  @p{««}I first heard about Bitcoin from this article: @p{»»}

    @p{(li}@p{(link}@s{(link)},2@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1671}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-27 17:45:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89725.msg994322@s{hash}msg994322
@section 3 {tx}

  @s{quotedtext}

  @p{««} See "Batch Mode" in the JSON 2.0 spec: @s{(link)} @p{»»}

  @p{««}Yes, you can request information about many unrelated transactions
  in one call. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1672}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-06-28 18:37:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=90513.msg996511@s{hash}msg996511
@section 3 {tx}

  @p{««}Several people have asked me privately via email what I think of
  Butterfly Labs and ASIC mining in general, so: @p{»»}

  @p{««}What do I think of ASICs hitting the "mining scene" ? @p{»»}

  @p{««}meh. @p{»»}

  @p{««}It shows that Bitcoin is considered stable enough for a company to
  invest a LOT of money on design and production on it, which is very
  good. ASICs were bound to happen if Bitcoin survived long enough. @p{»»}

  @p{««}The long-term outlook for mining is "mining will happen with very
  specialized hardware, in places where either electricity is free or
  generating lots of heat is a benefit and not a cost" (and probably both;
  I still think Iceland will be a big mining hot-spot eventually). @p{»»}

  @p{««}I'm not worried about Butterfly Labs deciding to take over the
  blockchain with their superior hashpower. They'd be idiots to do
  something like try to mount a 51% attack@p{--} they don't want to kill
  Bitcoin, they want it to get more successful so they sell more hardware.
  @p{»»}

  @p{««}And if they are successful they will very quickly have competitors.
  @p{»»}

  @p{««}Full disclosure: I spent some of my bitcoins to pre-order their USB
  coffee-warmer doo-hickey. It gets cold here in the winter. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1673}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-04 01:48:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=91474.msg1007248@s{hash}msg1007248
@section 3 {tx}

  @p{««}@s{code} is a valid, standard transaction
  type, redeemed by providing just {signature}. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1674}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-04 02:00:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=91397.msg1007262@s{hash}msg1007262
@section 3 {tx}

  @s{quotedtext}

  @p{««}I think Bitcoin is already perfectly capable of scaling up. Here's
  one half-baked idea for how to do it: @p{»»}

    @p{(li}@s{(link)} (pasted below to save you a click): @p{li)}

  @p{««}@p{hrule} The problem: is there a safe and secure way to make
  Bitcoin transactions without relying on the block-chain but, instead,
  relying on some semi-trusted third-party? @p{»»}

  @p{««}If there is, then Bitcoin is more easily scalable; most
  transactions could happen off the block chain, with in-the-block-chain
  transactions happening every once in a while to "settle up" off-chain
  transactions. @p{»»}

  @p{««}So here is the half-baked idea: @p{»»}

  @p{««}Use multisignature transactions to split the ownership of some
  bitcoin value between a customer (lets call her Alice) and a transaction
  service (lets call it "Joe's UltraTransactions" @p{--} Ultra for short).
  @p{»»}

  @p{««}Alice deposits 100 bitcoins into her Ultra wallet, and what
  actually happens behind the scenes is Alice's software generates a new
  keypair, gets a public key from Ultra, and coins are sent into a 2-of-2
  transaction. @p{»»}

  @p{««}Alice withdrawing the bitcoins (getting them out of the
  UltraTransaction system) is the boring case@p{--} she'd generate a
  transaction, sign her half, then ask Ultra to sign the other half (and
  there would be some sort of authentication check@p{--} maybe Ultra sends
  Alice an SMS to approve the withdrawal). @p{»»}

  @p{««}Now Alice wants to pay Bob 10BTC, who also happens to be an
  UltraTransaction customer. This is where things could get interesting.
  @p{»»}

  @p{««}Instead of generating a block-chain transaction, Alice could just
  give Bob her private key. Both Alice and Bob would sign a message with
  the private key saying "Alice is sending 10 bitcoins to Bob; she's given
  him the private key that she generated." Bob would send the message to
  Ultra, which would send Alice an SMS to make sure she approves, and then
  any withdrawal involving those 10 bitcoins associated with that private
  key would require Bob's authorization instead of Alice's. @p{»»}

  @p{««}Alice would still know the private key, but won't be able to spend
  what is now Bob's money (Ultra would only let her send/withdraw 90 of
  the 100 bitcoin tied up with that private key). @p{»»}

  @p{««}Ultra is only semi-trusted; it never has the private key, so can't
  spend the coins without either Alice or Bob's aproval. Joe can't decide
  to run off with everybody's coins when the Ultra wallet is worth a few
  million dollars. @p{»»}

  @p{««}Alice and Bob @p{(bf}do@p{bf)} have to trust that Ultra keeps track
  of who owns what accurately, and that Ultra will be around to sign it's
  half of the transaction when they want to withdraw some coin. And Bob
  has to trust that Alice did generate the private key, didn't share it
  with Ultra, and isn't actually Joe trying to trick him. @p{»»}

  @p{««}That's quite a lot of trust required, but the ability to instantly
  transfer value between Ultra customers with zero Bitcoin-block-chain
  transaction fees might outweigh the risks. And there are probably
  variations on this idea that would minimize trust in Ultra (maybe
  there's a semi-trusted service that Ultra pays to keep offline,
  "use-only-if-we-go-out-of-business" backups of their private keys).
  @p{»»}

  @p{««}And it scales beautifully; one UltraTransaction server cluster
  could easily handle hundreds or thousands of transactions per second,
  and you could imagine companies popping up all over the world, handling
  most transactions outside the blockchain.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1675}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-08 03:01:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92113.msg1015883@s{hash}msg1015883
@section 3 {tx}

  @p{««}Pieter is exactly right. The current code is extremely conservative
  with multisig addresses, only counting them as yours if the wallet
  contains @p{(bf}all@p{bf)} the private keys. @p{»»}

  @p{««}Loosening that to considering them yours if you have enough keys to
  spend might happen, although I am worried that might cause
  vulnerabilities for applications that make the implicit assumption that
  if they have the key necessary to spend that means nobody else can
  possibly spend those coins after 6 confirmations. If it is a 1of2
  multisig that wouldn't be true. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1676}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-09 15:20:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92403.msg1018853@s{hash}msg1018853
@section 3 {tx}

  @s{quotedtext}

  @p{««}Depending on what you're doing, you should support BIP 13:
  @s{(link)} @p{»»}

  @p{««}Also see: @s{(link)} for pseudo-code. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1677}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-10 13:29:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92558.msg1021055@s{hash}msg1021055
@section 3 {tx}

  @p{««}In case you don't subscribe to the @p{(link}bitcoin-development
  mailing list@p{link)}, we've been talking about a new BIP: @p{»»}

  @p{««}"Bitcoin blocks and transactions are versioned binary structures.
  Both currently use version 1. This BIP introduces an upgrade path for
  versioned transactions and blocks. A unique value is added to newly
  produced coinbase transactions, and blocks are updated to version 2."
  @p{»»}

  @p{««}Full BIP: @s{(link)} @p{brk} Mailing list discussion: @s{(link)}
  @p{brk} Pull request that implements BIP 34: @s{(link)} @p{brk} BIP16
  "Lessons learned" : @s{(link)} @p{»»}

  @p{««}I'd like to keep most discussion on the bitcoin-development mailing
  and not here on the forums, although I do plan on posting to one of the
  mining boards to warn solo miners and pool operators that they will
  eventually need to upgrade (I expect it will take at least a year and
  probably two or more for 95% of hashing power to upgrade, which is the
  proposed timeframe for full BIP 34 support).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1678}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-12 12:23:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92865.msg1025332@s{hash}msg1025332
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

  @s{quotedtext}

  @p{««}As Pieter said, they don't count towards your wallet balance
  because you don't have ALL of the private keys in your wallet. @p{»»}

  @p{««}It is not clear which wallet those 1-of-2 coins belong to, since
  neither has exclusive control over them. So the code is conservative and
  doesn't add them to your balance unless you have ALL of the private
  keys. @p{»»}

  @s{quotedtext}

  @p{««}The 0.7 release will have a set of RPC calls to create and sign
  transactions that spend from multisig inputs: see @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1679}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-13 00:54:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92804.msg1026657@s{hash}msg1026657
@section 3 {tx}

  @p{««}RE: 101 or 103 unused keys in the keypool: That's normal. Here's
  the sequence of events that causes it: @p{»»}

  @p{(li}  You do something that requests a new key from the keypool.
  Several things do that (including the 'getinfo' RPC call @p{--} it
  requests a key from the keypool so it can report the keypoololdest
  time).  @p{li)}

    @p{(li}@p{(li} The keypool automatically adds new keys so there are
    always at least 100 (by default) @p{li)} @p{(li} The something you did
    returns the key back to the keypool, so now there are 100+1 @p{li)}

  @p{««}I tend to have 104 keys in my keypools, because I do a lot of
  4-core CPU mining on testnet-in-a-box setups, and the 4 miner threads
  each grab a keypool key that is released when bitcoind quits. @p{»»}

  @p{««}RE: better backup: good idea. However, the keypool might not
  survive for much longer; they're likely to be replaced by Hierarchical
  Deterministic Wallets (see @s{(link)} ).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1680}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-13 13:27:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93092.msg1027702@s{hash}msg1027702
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, he ruffled a bunch of feathers by unilaterally changing
  bitcoin.org instead of submitting a pull request that could be tweaked
  and argued about. @p{»»}

  @p{««}You can see the discussion here:
  @p{(link}@s{(link)};forum_name=bitcoin-development@p{link)} 

# ----------------------------------------------------------------------
@section 2 {ms1681}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-13 19:59:03 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93092.msg1028598@s{hash}msg1028598
@section 3 {tx}

  @s{quotedtext}

  @p{««}Mmm. That's why if I were King I'd fast forward to a couple years
  from now when there were several mature bitcoin clients and bitcoin.org
  would not list any directly at all (see w3c.org for an example, you
  won't find a "Download a Web Browser Now!" link). @p{»»}

  @p{««}But I'm not King and unlike the Web there aren't a bunch of mature,
  well-funded bitcoin clients to choose from yet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1682}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-13 20:21:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=91732.msg1028651@s{hash}msg1028651
@section 3 {tx}

  @s{quotedtext}

  @p{««}Relevant recent IRC discussion:
  @p{(link}@s{(link)}@s{hash}l3981048@p{link)} @p{»»}

  @p{««}Bottom line: I think transaction replacement is important, but if
  we just enable it as-is then I think we open up the entire network to an
  easy DoS attack. @p{»»}

  @p{««}And I think the incentives for miners aren't right. I think the
  rule for what version of a transaction will be included in blocks has to
  be something like "the one that pays miners most OR the one that pays
  miners first (if there are several with the same fee)." @p{»»}

  @p{««}So I think a scheme where transaction fees are increased, or lock
  times are decreased, with every transaction replacement is the right way
  to go. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1683}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-13 23:53:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93174.msg1029161@s{hash}msg1029161
@section 3 {tx}

  @p{««}The upcoming 0.7 release will support running as a hidden service,
  and supports hidden services finding each other via the p2p and dnsseed
  peer-finding mechanisms; see @p{»»}

    @p{(li} @s{(link)} for information. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1684}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-14 00:14:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93092.msg1029227@s{hash}msg1029227
@section 3 {tx}

  @s{quotedtext}

  @p{««}Sure@p{--} I've always liked the BitTorrent/W3C model because it is
  less centralized (lots of different implementations of the protocol, as
  opposed to a project like Perl, where essentially everybody runs the
  same code). I consider Satoshi's code the "reference" client, though,
  not "proof-of-concept", since there is no formal specification. @p{»»}

  @p{««}(I've @p{(link}written a formal specification@p{link)}, and I think
  having a working reference implementation is better than An Officially
  Blessed Pile of Paper). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1685}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 13:12:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93502.msg1033958@s{hash}msg1033958
@section 3 {tx}

  @s{quotedtext}

  @p{««}What do you mean "send from A" ? Are A and B accounts or bitcoin
  addresses? @p{»»}

  @p{««}The reference client does not send coins "from" an address; when
  you send coins they are chosen from any of the available inputs in your
  wallet. @p{»»}

  @p{««}If you receive 50 BTC to an address associated with an empty
  account "A", then move those 50 bitcoins to account "B", then make the
  RPC call: @p{»»}

    @p{(li}sendfrom "A" @p{lt}to_address@s{gt} 50 @p{li)}

  @p{««}... you will get an error "Account has insuficient funds" @p{»»}

  @p{««} I have no idea what 2112 is talking about RE: accountants having
  trouble figuring out how the accounts feature operates. It is very much
  like separate accounts at a bank, where dollars and coins flow in, are
  credited to accounts, and then flow back out (debiting accounts). If I
  take a bag of cash to the bank and have it deposited into my account, I
  don't expect to get exactly the same bills and coins out the next time I
  make a withdrawal, and I shouldn't be surprised if the bank uses those
  coins and bills for withdrawals from other accounts. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1686}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 15:13:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93502.msg1034137@s{hash}msg1034137
@section 3 {tx}

  @s{quotedtext}

  @p{««}My bank must be weird, they let me withdraw more than X and let me
  carry a negative balance for a little while (a service they charge for).
  @p{»»}

  @p{««}With the accounts feature, if you have an account containing X
  bitcoins there are two ways to overdraw it: @p{»»}

    @p{(li} 1. Using the move command. Negative balances have a lot of
    use-cases, and last time I checked accountants know how to deal with
    negative account balances. @p{li)}

    @p{(li} 2. Using the sendfrom command, if a transaction fee is
    required then the fee is charged to the "sendfrom" account and may
    take it negative. @p{li)}

  @p{««}Are you sometimes using "sendtoaddress" and sometimes "sendfrom" ?
  Or are you using both the GUI (designed for a single user's wallet) and
  the RPC? If you want to use the accounts feature, don't do that, always
  use "sendfrom". @p{»»}

  @p{««}Better accounting for transaction fees is a valid complaint, always
  deducting the fee from the "sendfrom" account can be annoying. It
  doesn't violate accounting principles, though; if you want the
  transaction fee to be paid from some other account, then you just
  sendfrom() and then move() to adjust account balances. @p{»»}

  @p{««}If you really want to find something about the accounts feature to
  complain about, then you should complain that it doesn't scale. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1687}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 18:12:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93115.msg1034561@s{hash}msg1034561
@section 3 {tx}

  @p{««}Starting with OWASP is good advice. @p{»»}

  @p{««}But if you are holding other people's bitcoins, just securing the
  app is not enough. You need people who have experience securing
  @p{(bf}money@p{bf)} telling you how to create processes to make sure
  you're not the victim of embezzlement, that you are complying with legal
  requirements, keeping adequate records, keeping customers' funds
  separate from the funds used to pay expenses, that regular audits are
  done to detect problems early, and so on. @p{»»}

  @s{quotedtext}

  @p{««}+1 

# ----------------------------------------------------------------------
@section 2 {ms1688}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 20:07:10 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=87545.msg1034785@s{hash}msg1034785
@section 3 {tx}

  @s{quotedtext}

  @p{««}It was pulled into what will become the 0.7 release a while ago.
  @p{»»}

  @p{««}Documentation is now on the wiki: @s{(link)} @p{»»}

  @p{««}I decided not to abbreviate "transaction" @p{--} none of the other
  RPC calls use abbreviations. And the features have been tweaked a little
  bit. @p{»»}

  @p{««}There are some nice unintended-but-useful things you can do with
  it@p{--} as documented on the wiki page: @p{»»}

  @p{««}@p{(bf}Re-broadcast a transaction@p{bf)} @p{brk} If you want to
  re-broadcast a transaction right away, you can use the getrawtransaction
  and sendrawtransaction API calls to do that. As a bash shell-script
  one-liner it would be: @p{»»}

  @p{««}Code: sendrawtransaction $(getrawtransaction $TXID) (note that
  Bitcoin-Qt/bitcoind automatically re-transmit wallet transactions
  periodically until they are accepted into a block). @p{»»}

  @p{««}@p{(bf}Validate a transaction without broadcasting it@p{bf)}
  @p{brk} If you have a raw transaction and want to make sure all of it's
  signatures are correct, you can use the signrawtransaction API call.
  Pass in the hex-encoded raw transaction, any inputs that bitcoind
  doesn't yet know about, and an empty array of private keys to use to
  sign the transaction. Passing an empty array of private keys will
  prevent signrawtransaction from doing any signing; if it returns
  "complete":1 then all of the existing signatures are valid and there are
  no signatures missing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1689}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 20:19:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93660.msg1034814@s{hash}msg1034814
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1690}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-16 21:56:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93662.msg1035023@s{hash}msg1035023
@section 3 {tx}

  @s{quotedtext}

  @p{««}You'll be able to run as a 'hidden service' that is advertised to
  other nodes running on the Tor network and get incoming Tor connections
  in the next release. @p{»»}

  @p{««}See @s{(link)} for details (send thanks to Pieter Wuille for doing
  the work). @p{»»}

  @p{««}RE: hard drive space: Pieter has been busy optimizing HD usage, too
  ("@p{(link}ultraprune@p{link)}"), but that work isn't finished yet.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1691}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-17 01:18:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=74922.msg1035436@s{hash}msg1035436
@section 3 {tx}

  @p{««}I asked FINCEN about de-centralized virtual currencies a few weeks
  ago; here's what I got: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Only the first page is interesting. Reading between the lines, it
  looks like they're thinking about us. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1692}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-18 15:15:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93686.msg1038528@s{hash}msg1038528
@section 3 {tx}

  @p{««}That sounds more complicated than it needs to be. @p{»»}

  @p{««}If you can assume some mixers are honest and won't disclose what
  they added to the mix, then just do a series of pair-wise mixes. @p{»»}

  @p{««}E.g. @p{»»}

  @p{««}A and B communicate securely and create a transaction that has 2
  inputs and 2 outputs, all of the same amount of bitcoins (A and B might
  need to send-to-selves to get the right sized outputs). The output order
  is randomized. They each sign their input (after checking to make sure
  their output goes to them). @p{»»}

  @p{««}A could then repeat with C, then D and, assuming B, C, and D aren't
  all actually the same person recording his IP address and the mixes,
  would have a coins linked to the wallets of A/B/C/D. I believe after a
  few mixing steps a simple clustering analysis would think everybody who
  participated in the mix is sharing one big wallet (but I know very
  little about that stuff, and I wouldn't be surprised to find out there
  are more sophisticated clustering techniques that look at transaction
  times and overall transaction ordering that might be able to see through
  the fog and figure out who is who). @p{»»}

  @p{««}If all the other participants in the mixes are actually the same
  person (Sybil attack) then I believe no matter WHAT algorithm you use
  you're sunk. @p{»»}

  @p{««}My intuition is that if you can make the pairwise-mixing case work,
  then involving more than 2 people at once might be a useful
  optimization. But you should start with the 2-person case and prove it
  is secure before getting more complicated. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1693}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-19 13:48:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94106.msg1040742@s{hash}msg1040742
@section 3 {tx}

  @p{««}I am not a lawyer, but I believe the answer depends on how bitcoins
  are classified by the Securities and Exchange Commission. @p{»»}

  @p{««}If they're a currency then insider trading rules don't apply. But
  last time I looked the legal definition of 'currency' in the U.S. was
  the money issued by a recognized government. The only insiders for a
  currency are the people who issue it (I bet there are strict rules on
  trading of any kind by Treasury or Federal Reserve employees who have
  inside knowledge). @p{»»}

  @p{««}If Bitcoin gets classified as a commodity, then I'm not sure what
  rules apply. If an employee at Apple knows that the next generation iPad
  is going to use a lot of unobtanium, buys a bunch on the unobtanium
  exchange, then sells after the announcement for a profit are they guilty
  of insider trading? Probably... @p{»»}

  @p{««}If Bitcoin gets classified as a security, then I'm pretty sure
  insider trading rules would apply. @p{»»}

  @p{««}As always, if you're an employee at, oh, I dunno, Walmart and you
  know that Walmart will start accepting Bitcoin next March (I can dream,
  can't I?) and are tempted to buy a bunch of coin now I'd suggest you
  talk to a lawyer first. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1694}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-22 15:22:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94453.msg1046509@s{hash}msg1046509
@section 3 {tx}

  @s{quotedtext}

  @p{««}Gentle reminder to the other bitcoin developers: it is generally
  best not to feed trolls. Use the ignore button. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1695}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-23 01:02:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93001.msg1047333@s{hash}msg1047333
@section 3 {tx}

  @s{quotedtext}

  @p{««}That's a really great idea! @p{»»}

  @p{««}I think that's a type of all-pay auction; I wonder what an
  economist who's an expert on auctions would think.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1696}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-23 14:40:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94618.msg1048327@s{hash}msg1048327
@section 3 {tx}

  @p{««}Good advice that I expect will be widely ignored: only invest in
  what you know. @p{»»}

  @p{««}So-called high yield investments are (almost?) always dressed-up
  Ponzi schemes. If you "invest" in them then please lick your wounds
  quietly when they implode. And if you're one of the lucky few who make
  money on them, don't expect me to admire your investing wisdom, any more
  than I'd admire the number-picking brilliance of a lottery winner. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1697}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-23 20:24:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=93001.msg1049008@s{hash}msg1049008
@section 3 {tx}

  @s{quotedtext}

  @p{««} What partial pre-image? I assume the message being hashed is
  "Transfer THIS domain to THAT public key." (with probably a timestamp
  thrown in there that can't be too far ahead or behind current network
  time and, of course, a long nonce) @p{»»}

  @p{««}I imagine the hash-for-hire services would just ask their clients
  for the public key; I know I wouldn't want a hash-for-hire service to
  have access to my site's private key, they could sell it out from under
  me! @p{»»}

  @p{««}RE: a personal website or small domain being evicted: yep. You
  should offer to sell out for a couple bitcoins less than it will cost
  that big, evil corporation to find an eviction hash so at least you get
  compensated. There's very little difference between "legitimate little
  guy who's last name happens to be Ford" and "domain squatter." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1698}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-24 14:54:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94959.msg1050771@s{hash}msg1050771
@section 3 {tx}

  @p{««}There's a prettier version of this here: @s{(link)} @p{»»}

  @p{««}@p{(bf}Goal:@p{bf)} @p{brk} Multi-person 'cold storage' wallet,
  using the upcoming 0.7-release 'raw transactions' JSON-RPC api (geek's
  multisig): @p{»»}

  @p{««}@p{(bf}Setup:@p{bf)} @p{brk} Alice generate a public/private
  keypair. She prints them out and stores them somplace physically secure
  offsite as a backup. She secures the private key in a way she can easily
  access. @p{»»}

  @p{««}Bob does the same, then Alice and Bob exchange public keys and both
  form a 2-of-2 multisig address using addmultisigaddress and verify that
  it's the same for both of them. @p{»»}

  @p{««}0.1 BTC are sent to the multisig address, then Alice and Bob follow
  the spend procedure to make sure it works properly. If it does, the
  multisig address is fully funded as the secure 'cold' wallet. Public
  keys, multisig address, and funding/spending Transaction IDs and amounts
  are kept in a spreadsheet accessible to Bob and Alice (and potentially
  anybody else interested in auditing; Google Docs or DropBox or any other
  document-sharing solution works). @p{»»}

  @p{««}To detect security breaches, Alice and Bob should send a token
  amount of bitcoin (say 1 BTC) to the public keys that they are using,
  and should never spend those coins. Both addresses should be monitored
  by both Alice and Bob, and if they see coins being spent they should
  assume that the corresponding private key has been compromised and
  transfer the multisignature coins to a new, secure multisig address with
  fresh keys generated on devices that have not been compromised. @p{»»}

  @p{««}@p{(bf}Spend:@p{bf)} @p{brk} Alice selects enough unspent
  transactions to withdraw the amount she wants and cover fees. She
  updates the Google Doc document and marks the funding transactions as
  'PENDING SPEND'. @p{»»}

  @p{««}She calls createrawtransaction with those inputs and one or two
  outputs: @p{»»}

    @p{(li}Output to the address where the withdrawal is going@p{li)}

    @p{(li}Change output, back to the multisig address@p{li)} She calls
  signrawtransaction, passing in her private key, and then send the
  half-signed transaction to Bob (via email or any other method). @p{»»}

  @p{««}Bob calls decoderawtransaction and checks with Alice to make sure
  the transaction is OK (Bob and Alice either communicate in advance via
  phone or Bob calls Alice to verify the transaction details). @p{»»}

  @p{««}Assuming all is OK, Bob calls signrawtransaction and then
  sendrawtransaction to broadcast to the network. He marks the PENDING
  SPEND inputs in the shared spreadsheet 'SPENT', and adds the change
  output (if any) to the spreadsheet as a new potential input for future
  spends. @p{»»}

  @p{««}@p{(bf}Variations/notes:@p{bf)} @p{brk} Depending on the level of
  security felt to be necessary, securing the private keys might involve
  encrypting them with pgp and a passhprase and storing them encrypted on
  the computer or in the cloud. Or storing them in a LastPass secure note.
  Or storing them on a passphrase-protected IronKey USB stick. Alice and
  Bob don't necessarily have to follow the same procedure for securing
  their private keys. @p{»»}

  @p{««}If Alice or Bob suffer any sort of security breach or some period
  of time goes by (1 year?), they should generate new keys and a new
  address and send all funds to the new address. @p{»»}

  @p{««}If Alice and Bob do this more than twice, a little front-end tool
  that automated much of the process would be a worthwhile investment;
  that tool could be a prototype for adding complete multisig support to
  Bitcoin-Qt. Then again, it might just be easier to add support to
  Bitcoin-Qt in the first place. @p{»»}

  @p{««}Extending this so any two of (Alice,Bob,Carol) can authorize a
  transaction out of the wallet is straightforward, and would prevent loss
  of funds if any one of them completely lost access to their private key.
  Or if even more security is needed then requiring all three authorize
  withdrawals is also straightforward. @p{»»}

  @p{««}Sending the change back into the same multisig address is somewhat
  bad for both security (the public keys associated with the address are
  revealed at the first spend transaction) and privacy. This can also
  easily be extended to use two (or more) Hierarchical Deterministic Keys
  (see BIP 32), with a new multisig address generated for any change on
  every withdrawal. @p{»»}

  @p{««}Alice and Bob might be one person, of course, using two different
  computers.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1699}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-24 18:02:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=173.msg1051108@s{hash}msg1051108
@section 3 {tx}

  @s{quotedtext}

  @p{««} In a wisdom-of-crowds system, the @p{(it}promise@p{it)} comes from
  faith that somebody in the future will still find bitcoins valuable, and
  be willing to give you @p{(it}something@p{it)} in return. @p{»»}

  @p{««}True, it isn't a promise from one particular institution or person
  to redeem for one particular something else, so it doesn't fit
  @p{(bf}your@p{bf)} definition of 'backing.' But I trust The Crowd more
  than I trust any one particular institution (especially institutions
  like governments, who have a long history of breaking promises). @p{»»}

  @p{««}See my recent "@p{(link}Is store of value enough?@p{link)}" blog
  post for more thoughts along these lines. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1700}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-24 18:57:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94959.msg1051217@s{hash}msg1051217
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, but if Bob and Alice keep the 2-of-2 multisig address secret,
  then you, the rat, will have no idea that they key you managed to steal
  is one of the two keys needed to open the fridge. @p{»»}

  @p{««}That's why I say that sending the change back into the same
  multisig address every time is somewhat bad for security... @p{»»}

  @s{quotedtext}

  @p{««}Yes, that was announced before (see the thread about the raw
  transactions api). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1701}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-24 19:10:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94959.msg1051242@s{hash}msg1051242
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes@p{--} bitcoind creates BIP16 multisig transactions (using
  BIP13 addresses). Because a BIP16 transaction doesn't reveal public keys
  until the first spend, if an attacker has only one of the public keys
  (and the multisig address has been funded but never spent) they won't be
  able to figure out that the key is helping to protect a large
  multisig-protected balance. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1702}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-25 13:46:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=95116.msg1053104@s{hash}msg1053104
@section 3 {tx}

  @s{quotedtext}

  @p{««}That makes sense. If you think BCX will succeed and are immoral,
  then the way to profit at the exchange's expense is transfer a lot of
  LTC in to an exchange and sell them for BTC during the fork. @p{»»}

  @p{««}If the attack is successful then the LTC deposit is rolled back and
  you can sell them again. Assuming there is somebody still willing to buy
  them. @p{»»}

  @p{««}In any case, lots of buying before the attack then lots of selling
  while the fork is being created is the pattern I would expect to see. Of
  course, that is the same pattern as a plain pump-and-dump scheme...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1703}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-25 19:20:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94999.msg1053771@s{hash}msg1053771
@section 3 {tx}

  @s{quotedtext}

  @p{««}"We" thought of that (where "we" was actually Khalahan and Pieter
  and Gregory, if I recall correctly). @p{»»}

  @p{««}The string "Bitcoin Signed Message:\n" is prepended to the message
  as salt, then that's SHA256-hashed twice, and the hash is what is
  signed/verified. Sign anything you like, it won't reveal information
  about your keys (unless your OpenSLL implementation has a broken random
  number generator and doesn't @p{(link}generate unique signing
  nonces@p{link)}).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1704}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-25 19:34:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94822.msg1053810@s{hash}msg1053810
@section 3 {tx}

  @p{««}For the voting problem: @p{»»}

  @p{««}It would probably be best to give each voter a "yes" and "no"
  address that they are expected not to share with anybody else. They can
  then vote by sending the right number of bitcoins to one of those
  addresses. @p{»»}

  @p{««}You can decide what happens if they send to both addresses. @p{»»}

  @p{««}If you want the vote results to be public, then you can pre-publish
  before the vote a hash of the list of all addresses and voters. Then
  after the vote publish the list; everybody can make sure it hashes to
  the correct value, that it has the right list of voters, that it has
  twice as many addresses as voters, and each voter can check to make sure
  the addresses assigned to them are on the list. @p{»»}

  @p{««}And the voters could then look at the transactions in the
  blockchain during the voting period, to those addresses to audit the
  vote. @p{»»}

  @p{««}There's probably a complicated crypto protocol you could put on top
  to make the votes anonymous-but-verifiable, too @p{--} so even the vote
  organizer doesn't know who voted for what.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1705}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-25 23:31:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86679.msg1054335@s{hash}msg1054335
@section 3 {tx}

  @s{quotedtext}

  @p{««}Self-correcting assuming there are good market dynamics between
  miners and users. That's broken right now, but I'm working on fixing it
  (see @p{(link}pull @s{hash}1590@p{link)} for the first step).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1706}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-26 13:31:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=86679.msg1055812@s{hash}msg1055812
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, partly. @p{»»}

  @p{««}The most important change is having miners sort transactions by
  fee-per-kilobyte, and prefer higher-fee transactions to lower-fee
  transactions. That way users that want their transactions to get
  confirmed quickly can pay a higher-than-average fee. Today, most miners
  are using the reference code which selects transactions based on
  priority, not fee. @p{»»}

  @p{««}Still todo: give better recommendations to users about how long it
  might take their transaction to get confirmed if they send it without a
  fee, and recommend an appropriate fee. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1707}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-26 16:57:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=95837.msg1056322@s{hash}msg1056322
@section 3 {tx}

  @p{««}I just sent this email to the biggest mining pool operators; I
  think creating a real market between users and miners to set transaction
  fees is a very high priority. @p{»»}

  @p{««}@p{hrule} After a lot of thinking, trying a few different
  implementations, and a couple days of testing I'm finally happy with a
  new scheme for selecting which transactions to include in created
  blocks. @p{»»}

  @p{««}Patch for version 0.6.3: @p{brk} @s{(link)} @p{»»}

  @p{««}This is @p{(link}pull request @s{hash}1590@p{link)} and will very likely
  be part of the upcoming 0.7 release. @p{»»}

  @p{««}Backported patch for version 0.3.24 if you're stuck on an old
  version of bitcoind: @p{brk} @s{(link)} @p{»»}

  @p{««}These add new command-line / bitcoin.conf options: @p{»»}

  @s{code}

    @p{(li}-blockminsize=0 @p{li)}

    @p{(li}-blockprioritysize=27000 @p{li)}

    @p{(li}-mintxfee=0.0005 @p{brk} The above settings are the default,
   and match the current default behavior. If you are using a stock
   bitcoind to create your blocks and apply the patch, the only difference
   you will see is a higher block reward, because the new code prefers
   transactions with higher fees to transactions with lower fees. @p{»»}

  @p{««}The new options let you control your transaction acceptance policy
  without recompiling; here is what they do and how to use them: @p{»»}

  @p{««}-blockmaxsize controls the maximum size of blocks created, in
  bytes. I know some pools are limiting the size of the blocks they create
  because they think larger blocks are more likely to be orphaned; this
  setting lets you do that easily. Reasonable values are between 50,000
  and 250,000 bytes. @p{»»}

  @p{««}-blockminsize lets you fill up any 'extra' space in blocks with
  free transactions, until the block is -blockminsize bytes big. You can
  use this to implement a policy of "Fill up the block with fee-paying
  transactions first, but if there aren't enough then include free
  transactions." Reasonable values are 0 to blockmaxsize. @p{»»}

  @p{««}-blockprioritysize is the primary way to support free transactions.
  This many bytes at the beginning of the block are set aside for the
  highest priority transactions, regardless of whether or not they pay a
  fee. Reasonable values are 0 to blockmaxsize. @p{»»}

  @p{««}-mintxfee is the minimum fee, measured in bitcoins-per-1,000-bytes,
  for a transaction to be considered 'paid' instead of 'free.' It should
  ideally be a little larger than your real-world cost to process a
  transaction. Reasonable values are 0.0001 to 0.01 (setting this too low
  is dangerous; a transaction spammer can fill up your blocks with
  very-low-but-non-zero-fee transactions) @p{»»}

  @p{««} @p{hrule} So, putting it all together, here are some possible fee
  policies you might want to follow: @p{»»}

  @p{««}CREATE SMALLER BLOCKS @p{»»}

  @p{««}You want to limit the size of the blocks you create so they
  propagate faster. @p{»»}

   @s{code}

  @p{««} PUNISH HIGH-FREQUENCY USERS @p{»»}

  @p{««}You want to mostly include transactions based on priority, to
  discourage SatoshiDice-like services where people are sending blizzards
  of low-value transactions. But you still want to pick up any
  large-transaction-fee transactions. @p{»»}

   @s{code}

  @p{««} MAXIMUM FEES @p{»»}

  @p{««}You want to maximize your block reward, including as many
  fee-paying transactions as possible but avoiding all free transactions.
  @p{»»}

   @s{code}

  @p{««} mintxfee=0.0001 @p{»»}

  @p{««}MAXIMUM FEES, ALLOW FREE @p{»»}

  @p{««}You want to maximize the fees you get, but allow some free
  transactions if transaction volume on the network is low. @p{»»}

   @s{code}

  @p{««} MAXIMUM COMPATIBILITY WITH EXISTING CLIENTS @p{»»}

  @p{««}If you want the best compatibility with Bitcoin-Qt and other
  existing clients, use the default values. @p{»»}

  @p{««} @p{hrule} @p{brk} Next on my TODO list: implement client-side code
  to figure out what the average miner's fee policy is by looking at how
  quickly transactions are being accepted into blocks, and recommend a
  reasonable fee to users on a per-transaction basis.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1708}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-27 23:48:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=96097.msg1059475@s{hash}msg1059475
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good question. @p{»»}

  @p{««}In my humble opinion, the block size should not be arbitrarily
  limited as it is now (1MB is the limit; typical blocks these days are
  30-250K big), but should 'float' @p{--} miners should collectively
  decide how large a block they're willing to validate and build on top
  of. @p{»»}

  @p{««}Obviously a miner wants to include as many fee-paying transactions
  in their blocks as possible, until the fee paid is less than their cost
  of validating and including the transaction (which is a small cost).
  @p{»»}

  @p{««}But miners also don't want to spend a very long time validating
  other miners' blocks, so they have an incentive to ignore blocks that
  are outrageously big. If they @p{(it}were@p{it)} willing to build on a
  10-gigabyte-big block that took ten minutes to download and signature
  check, then they're shooting themselves in the foot@p{--} an evil miner
  could mine a huge block, and then get a head start on mining the next
  block while the rest of the network was busy validating it. @p{»»}

  @p{««}BUT: moving to a floating maximum block size determined by miners
  will be really hard; it will require everybody@p{--} merchants and
  miners and users@p{--} to upgrade. It may never happen, because other
  ways of supporting very high transaction volumes might develop before
  then.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1709}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-30 17:22:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=43616.msg1065504@s{hash}msg1065504
@section 3 {tx}

  @s{quotedtext}

  @p{««}That's not quite right. @p{»»}

  @p{««}The protocol supports it@p{--} just take the output of an
  unconfirmed transaction (paying to you) and then broadcast a
  send-to-self transaction that uses it as input and has a big, juicy fee.
  @p{»»}

  @p{««}I think the Eligius mining pool might even notice and confirm both
  transactions@p{--} Luke DashJr has a @p{(link}pull request@p{link)} to
  change the reference implementation's transaction selection code to
  consider fees for sets of related transactions when deciding what to
  include in a block. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1710}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-30 17:34:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=96548.msg1065541@s{hash}msg1065541
@section 3 {tx}

  @p{««}Thoughts: @p{»»}

  @p{««}We need better authorization and authentication for payments. See
  @s{(link)} for my complete thoughts; the "are you paying who you think
  you are paying" process is relevant even if you're using a singlesig
  wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1711}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-07-31 21:06:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=95795.msg1068895@s{hash}msg1068895
@section 3 {tx}

  @p{««}For the record: @p{»»}

  @p{««}I've never met Zhou Tong, and wasn't involved in any with with
  Bitcoinica. @p{»»}

  @p{««}I @p{(bf}have@p{bf)} met Tihan, Charlie and Patrick (Murck), and
  they are all responsible grown-ups who, like any of us, occasionally
  make mistakes. I think they're making a mistake getting stuck to the
  Bitcoinica @p{(link}tar-baby@p{link)}, but I think y'all should give
  them a little space because I think they're genuinely trying to help
  clean up this mess. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1712}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-01 15:43:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=97153.msg1070764@s{hash}msg1070764
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{(li} 1 to Sergio's points, too. Casascius: I think you need to think
  more like an attacker; if they @p{(it}can@p{it)} cheaply mount an
  attack, then they @p{(bf}will@p{bf)}. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1713}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-13 15:04:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=100213.msg1096638@s{hash}msg1096638
@section 3 {tx}

  @s{quotedtext}

  @p{««} I wrote up a step-by-step guide for secure two-person cold-storage
  escrow using the new 'raw transactions' api: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1714}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-17 03:59:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101191.msg1106017@s{hash}msg1106017
@section 3 {tx}

  @p{««}So while driving across Wyoming today my mind wandered to
  proof-of-stake. And whether or not it would be possible to attack a
  proof-of-stake system by repeatedly sending expensive to verify but
  invalid proofs of stake. @p{»»}

  @p{««}I think you could. @p{»»}

  @p{««}Example: if the proof-of-stake involves creating a bunch of valid
  signatures using private keys that you own, then an attacker could buy
  or create a few thousand keys (e.g. buy 10,000 units of currency and
  then split them into 10,000 addresses) and submit a proof-of-stake where
  9,999 signatures are valid and the last one is invalid. @p{»»}

  @p{««}The proof-of-stake will fail, but it will cost the victims
  approximately the same CPU time to find that out as it takes the
  attacker to generate the signatures. If the attacker can repeatedly send
  the same proof-of-stake, and the victims don't cache the work of
  checking the signatures, then you've got the basis for a great
  denial-of-service attack. @p{»»}

  @p{««}Proof-of-work doesn't suffer from this attack, because it is MUCH
  easier to validate proof-of-work (one hash operation) than to generate
  it. I haven't thought deeply about whether or not you could come up with
  a proof-of-stake that has the same "hard to generate, easy to validate"
  property. I suppose you could require that a proof-of-stake have a
  small, limited number of signatures@p{--} requiring that stakeholders
  maintain a small number of large-balance addresses. That's bad for
  privacy and security, though. @p{»»}

  @p{««}You could disconnect/ban peers that submit invalid proofs-of-stake;
  an attacker would have to mount a Sybil attack using lots of IP
  addresses to get around that. That might be a problem in an IPv6 world
  of essentially infinite IP addresses, though... @p{»»}

  @p{««}A hybrid system that requires proof-of-work AND proof-of-stake
  might work. You'd have to be careful to tie the proof-of-stake to the
  proof-of-work, though, otherwise an attacker might be able to re-use the
  same proof-of-work over and over. @p{»»}

  @p{««}I'm curious: if you've been working on a proof-of-stake system, is
  this kind of attack the kind of thing you've already thought about and
  solved? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1715}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-17 04:23:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101146.msg1106081@s{hash}msg1106081
@section 3 {tx}

  @p{««}Before I left for vacation, I submitted @p{(link}a pull
  request@p{link)} that makes the default policy for miners "more fees ==
  more likely to get into a block." That will be in the 0.7 release (the
  policy before was mostly "higher priority == more likely to get into a
  block"), and I've been encouraging the big mining pool operators to
  implement something similar if they have their own transaction-selection
  code. @p{»»}

  @p{««}When I get back from vacation I plan on writing code to watch the
  transactions that do or do not make it into blocks to derive an estimate
  of the average miners' fee policy, and use that to recommend a
  reasonable fee to the user. @p{»»}

  @p{««}Those changes will let fees float naturally@p{--} users and miners
  will form a market and fees will rise or fall based on what users are
  willing to pay and what miners are willing to accept. I don't like the
  arbitrary, centralized setting of fees that we've had up until now.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1716}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-18 02:25:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101011.msg1109440@s{hash}msg1109440
@section 3 {tx}

  @p{««}All right, all right, enough speculation. @p{»»}

  @p{««}I'll be announcing @s{(link)}, where you will be able to buy
  high-quality Alpaca wool undergarments for bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1717}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-19 15:55:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101191.msg1113133@s{hash}msg1113133
@section 3 {tx}

  @s{quotedtext}

  @p{««}From the whitepaper: @p{»»}

  @s{quotedtext}

  @p{««} I'd have to think about it a lot harder than I'm willing to right
  now to be absolutely sure, but that seems like a mistake to me. @p{»»}

  @p{««}If peers have to fetch inputs and compute coin age to determine
  whether or not a chain is longest then it seems like that could be
  leveraged into a denial-of-service attack. Because an attacker could do
  minimal proof-of-work (or proof-of-stake) but then broadcast a chain
  with @p{(it}JUST@p{it)} a little-less consumed coin age than the current
  best chain. @p{»»}

  @p{««}Their chain will be rejected, but their peers will waste time
  figuring out that it should be rejected. @p{»»}

  @p{««}Also note that Bitcoin does NOT use total proof-of-work-performed
  to determine the best chain; it uses total proof-of-work-target. That's
  deliberate; if it used proof-of-work-performed, then if you happened to
  get lucky and found an extremely small block hash you could hold on to
  it, build on top of it, and only announce your "more proof of work"
  chain when the network chain's work started to catch up with your secret
  chain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1718}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-19 16:01:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101686.msg1113153@s{hash}msg1113153
@section 3 {tx}

  @p{««}From an email I sent to somebody concerned about bitcoin usability
  just a couple of days ago: @p{»»}

  @p{««}Making the reference Bitcoin application more usable isn't a high
  priority for me right now. @p{»»}

  @p{««}The high priority is making it safe to use, even if your computer
  gets infected by malware. I @p{(bf}WANT@p{bf)} it to be hard and geeky
  to use so only geeks who are able to keep their computers secure run it.
  @p{»»}

  @p{««}Also, the "download and run software on my computer" way of doing
  things is dying. The vast majority of ordinary users will be using
  Bitcoin on their smart-phones or through a web browser in the near
  future.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1719}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-21 13:16:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101818.msg1119717@s{hash}msg1119717
@section 3 {tx}

  @p{««}Is bitcoin 2 coming out next month? @p{»»}

  @p{««}No. @p{»»}

  @p{««}Everybody knows eleven is my favorite number, so if there
  @p{(bf}was@p{bf)} going to be a major release of bitcoin it would be
  "Bitcoin 11". But it ain't gonna happen. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1720}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-21 18:37:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=102194.msg1120659@s{hash}msg1120659
@section 3 {tx}

  @s{quotedtext}

  @p{««} See @s{(link)} . Specifically, the section that starts "Example:
  re-define OP_NOP1 to be OP_Q_CHECKSIGVERIFY, using a quantum-resistant
  digital signature algorithm." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1721}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-22 02:42:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=102395.msg1122044@s{hash}msg1122044
@section 3 {tx}

  @p{««}Zooko Wilcox-O'Hearn also deserves recognition; he warned us that
  the method Bitcoin uses to compute the Merkle tree was possibly insecure
  (although at the time we couldn't see how to turn it into an exploit).
  @p{»»}

  @p{««}This was a nasty bug; if Forrest hadn't found it and responsibly
  reported it, an attacker probably could have stopped most of the nodes
  on the network before we got patched code out. It is bugs like this that
  make me think that having several different implementations of the
  Bitcoin protocol is a good idea. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1722}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-22 03:16:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=102194.msg1122114@s{hash}msg1122114
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}I think I've said it before, but I'll say it again: I'll start to
  worry when there is a quantum computer that can factor 64-bit numbers
  faster than non-quantum computers. I bet that is at least 20 years
  away... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1723}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-22 03:21:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=100696.msg1122120@s{hash}msg1122120
@section 3 {tx}

  @p{««}From this very relevant article: @p{»»}

    @p{(li}@p{(link}"Megan McArdle on Arbitrage and Why We Love Being
    Conned"@p{link)} @p{li)}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1724}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-22 14:22:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8392.msg1123472@s{hash}msg1123472
@section 3 {tx}

  @p{««}Making transactions with non-DER-encoded (aka BER encoded)
  signatures non-standard has been on my TODO list for over a year now,
  but has never been the highest priority. That's the first step to making
  non-DER-encoded signatures completely illegal. @p{»»}

  @p{««}Note that if there is a core-dumping bug in OpenSSL's decoding code
  then it needs to get fixed in OpenSSL. Writing a BER decoder just for
  Bitcoin is a bad idea, it is much more likely our new code would have a
  crashing bug. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1725}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-22 21:53:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=102349.msg1124573@s{hash}msg1124573
@section 3 {tx}

  @p{««}RE: seeds with a lot of entropy: @p{»»}

  @p{««}Every time I look at the academic literature on
  passwords/passphrases, I get more depressed about the feasibility of
  either giving users a secure passphrase that they will remember or
  getting a secure passphrase from them. I fear there will be a lot of
  lost coins if "brain wallets" get popular. @p{»»}

  @p{««}E.g. this 2012 paper: @s{(link)} @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1726}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-23 13:41:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=102606.msg1126479@s{hash}msg1126479
@section 3 {tx}

  @p{««}EITHER: requiring that the wallet be unlocked for the settxfee RPC
  call to succeed @p{brk} OR: adding a new configuration option
  "-maxtxfee" (default: 0.01 maybe) that can't be set via RPC @p{brk} ...
  seems reasonable to me. @p{»»}

  @p{««}We've had an implicit assumption that if an attacker gets access to
  the RPC interface you're sunk, and while I think that's true (attacker
  could run a tight loop of "sendtoaddress" that will fail until the
  moment you unlock the wallet to send some bitcoins somewhere), I also
  think security in depth is a good idea. @p{»»}

  @p{««}Can you open an issue on github please? @p{»»}

  @p{««}RE: gui not telling you about the fee: @p{»»}

  @p{««}Can you open a separate issue on github about that, too? That's
  just a bug, in my humble opinion.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1727}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-23 14:11:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=100944.msg1126554@s{hash}msg1126554
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, the main reason isn't anonymity the reason is so transferring
  bitcoins between accounts using 'move' doesn't require a blockchain
  transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1728}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-25 16:05:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=103172.msg1132207@s{hash}msg1132207
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't think a new signature algorithm doesn't require a hard
  fork; redefine an OP_NOP as OP_CHECKSIGVERIFY2 that uses ed25519, create
  a new 'standard' transaction type that uses that new opcode, and a new
  bitcoin address type that corresponds to it, then start by rolling out
  miner support, etc. as sketched out @p{(link}here@p{link)}. @p{»»}

  @p{««}That would probably be better than a hard fork; I'm not sure what
  the transition plan would look like for old transactions if OP_CHECKSIG
  was redefined to use the ed25519 curve. @p{»»}

  @p{««}If the new transaction type was significantly cheaper, then cheaper
  transaction fees could incentivize people to upgrade their
  clients/wallets. @p{»»}

  @p{««}I don't think now is the right time to do any of that, mostly
  because I wouldn't be surprised if some solution for instant "off the
  chain" payments is adopted instead, in which case perhaps sep256k1
  transaction cost will be negligible. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1729}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-25 18:14:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=103172.msg1132449@s{hash}msg1132449
@section 3 {tx}

  @s{quotedtext}

  @p{««}That's wrong; you wouldn't be able to send a new-style transaction
  to a merchant unless they'd already upgraded and were publishing
  new-style addresses. @p{»»}

  @p{««}... which would actually just be BIP16 addresses, with the
  redemption script being something like @p{lt}ed25519_pubkey@s{gt}
  OP_NOP1 @p{brk} (I'm wrong about needing a new bitcoin address type).
  @p{»»}

  @p{««}Obviously merchants wouldn't start doing that until a majority of
  miners were interpreting OP_NOP1 as OP_ED25519_VERIFY. @p{»»}

  @s{quotedtext}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1730}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-25 21:15:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=103258.msg1132776@s{hash}msg1132776
@section 3 {tx}

  @s{quotedtext}

  @p{««}The attacker will pay transaction fees to send those spammy inputs,
  and that has been a large enough disincentive that it hasn't happened.
  @p{»»}

  @p{««}That said, SelectCoins aught to be improved; ideally, it should
  never include an input if the fee for adding that input is greater than
  that input's value. @p{»»}

  @p{««}Or maybe it should just ignore inputs below the 'spam transaction'
  threshold for now, as being more trouble than they're worth. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1731}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-26 19:05:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=103172.msg1134832@s{hash}msg1134832
@section 3 {tx}

  @s{quotedtext}

  @p{««}Right, that was one of the lessons learned from BIP16@p{--}
  transactions redeeming non-standard inputs aught to be treated as
  non-standard. And they are, as of v0.6 (I think, I'm really good at
  forgetting when changes were introduced). @p{»»}

  @p{««}If the merchant is using stock bitcoind, then the non-standard
  transaction won't show up in their wallet until it appears in a block
  with 1 confirmation, making the security downgrade non-existent (it
  becomes a variation on the Finney attack). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1732}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-28 19:08:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104110.msg1140651@s{hash}msg1140651
@section 3 {tx}

  @s{quotedtext}

  @p{««} If I recall correctly, the first testnet-in-a-box node should have
  all the coins. The second starts with a zero balance / empty wallet
  (send it coins from the first if you need to...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1733}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-28 20:02:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104173.msg1140771@s{hash}msg1140771
@section 3 {tx}

  @p{««}Bitcoin version 0.7.0 release candidate 1 binaries are now
  available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Please use the issue tracker at @s{(link)} to report bugs. @p{»»}

  @p{««}Notable changes: @p{»»}

  @p{««}Security @p{»»}
  
  @p{««}* Fixed
  denial-of-service attacks (disk and CPU exhaustion) related to the alert
  system @p{»»}

  @p{««}Qt GUI  @p{brk} * Add UI RPC console
  / debug window @p{brk} * Re-Enable URI handling on Windows, add safety
  checks and tray-notifications @p{brk} * Add 2 labels to the overviewpage
  that display Wallet and Transaction status (obsolete or current) @p{brk}
  * Extend the optionsdialog (e.g. language selection) and re-work it to a
  tabbed UI @p{brk} * Merge sign/verify message into a single window with
  tabbed UI @p{brk} * Improve error reporting at startup @p{brk} *
  Fine-grained UI updates for a much smoother UI during block downloads
  @p{brk} * Reorganize tray icon menu into more logical order @p{brk} *
  Persistently poll for balance change when number of blocks changed
  @p{brk} * Much better translations @p{brk} * Added 'immature balance'
  display on the overview page @p{brk} * (Windows only): enable ASLR and
  DEP for bitcoin-qt.exe @p{brk} * (Windows only): add meta-data to
  bitcoin-qt.exe (e.g. description) @p{»»}

  @p{««}Bitcoin Improvement Proposals implemented 
  @p{brk} @p{(link}BIP 22@p{link)} - 'getblocktemplate', 'submitblock'
  RPCs @p{brk} @p{(link}BIP 34@p{link)} - block height in coinbase @p{brk}
  @p{(link}BIP 35@p{link)}- 'mempool' message, extended 'getdata' message
  behavior @p{»»}

  @p{««}Core bitcoin handling and blockchain database 
  @p{brk} * Reduced CPU usage, by eliminating some redundant hash
  calculations @p{brk} * Cache signature verifications, to eliminate
  redundant signature checks @p{brk} * Transactions with zero-value
  outputs are considered non-standard @p{brk} * Mining: when creating new
  blocks, sort 'paid' area by fee-per-kb @p{brk} * Database: better
  validation of on-disk stored data @p{brk} * Database: minor
  optimizations and reliability improvements @p{brk} * -loadblock=FILE
  will import an external block file @p{»»}

  @p{««}JSON-RPC API 
  @p{brk} * Internal HTTP server is now thread-per-connection, rather than
  @p{»»}

    @p{(li}a single-threaded queue that would stall on network I/O.
  @p{li)} * Internal HTTP server supports HTTP/1.1, pipelined requests and
  @p{»»}

    @p{(li}connection keep-alive. @p{li)} * Support JSON-RPC 2.0 batches,
  to encapsulate multiple JSON-RPC requests @p{»»}

    @p{(li}within a single HTTP request. @p{li)} * IPv6 support @p{brk} *
  Added raw transaction API. See @s{(link)} @p{brk} * Added
  'getrawmempool', to list contents of TX memory pool @p{brk} * Added
  'getpeerinfo', to list data about each connected network peer @p{brk} *
  Added 'listaddressgroupings' for better coin control @p{brk} * Rework
  gettransaction, getblock calls. 'gettransaction' responds for @p{»»}

    @p{(li}non-wallet TXs now. @p{li)} * Remove deprecated RPC
  'getblocknumber' @p{brk} * New blockchain checkpoint at block 193,000
  @p{brk} * listtransactions output now displays "smart" times for
  transactions, @p{»»}

    @p{(li}and 'blocktime' and 'timereceived' fields were added @p{li)}

  @p{««} P2P networking  @p{brk} * IPv6
  support @p{brk} * Tor hidden service support @p{brk} * Attempts to fix
  "stuck blockchain download" problems @p{brk} * Replace BDB database
  "addr.dat" with internally-managed "peers.dat" @p{»»}

    @p{(li}file containing peer address data. @p{li)} * Lower default send
  buffer from 10MB to 1MB @p{brk} * proxy: SOCKS5 by default @p{brk} *
  Support connecting by hostnames passed to proxy (-proxydns) @p{brk} *
  Add -seednode connections, and use this for -dnsseed + -proxydns @p{brk}
  * Added -externalip and -discover @p{brk} * Add -onlynet to connect only
  to a given network (IPv4, IPv6, or Tor) @p{brk} * Separate listening
  sockets, -bind=@p{lt}addr@s{gt} @p{»»}

  @p{««} Internal codebase  @p{brk} *
  Additional unit tests @p{brk} * Compile warning fixes @p{»»}

  @p{««}Miscellaneous @p{brk}  * Reopen debug.log upon SIGHUP @p{brk} * Bash programmable
  completion for bitcoind(1) @p{brk} * On supported OS's, each thread is
  given a useful name @p{»»}

  @p{««}Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Chris Moore @p{brk} Christian von Roques @p{brk} David Joel
  Schwartz @p{brk} Douglas Huff @p{brk} Fordy @p{brk} Gavin Andresen
  @p{brk} Giel van Schijndel @p{brk} Gregory Maxwell @p{brk} Jeff Garzik
  @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk}
  Michael Hendricks @p{brk} Peter Todd @p{brk} Philip Kaufmann @p{brk}
  Pieter Wuille @p{brk} R E Broadley @p{brk} Ricardo M. Correia @p{brk}
  Rune K. Svendsen @p{brk} Scott Ellis @p{brk} Stephane Glondu @p{brk}
  Wladimir J. van der Laan @p{brk} cardpuncher @p{brk} coderrr @p{brk}
  fanquake @p{brk} grimd34th @p{brk} sje397 @p{brk} xanatos @p{»»}

  @p{««}Thanks to Sergio Lerner for reporting denial-of-service
  vulnerabilities fixed in this release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1734}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-29 18:07:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104460.msg1143929@s{hash}msg1143929
@section 3 {tx}

  @p{««}If you do it, I'd suggest implementing it as a proxy that sits in
  front of bitcoind. @p{»»}

  @p{««}But before you do that, you should do some googling to see if
  somebody has already written a JSON-RPC-over-HTTP proxy that implements
  per-method access control. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1735}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-29 20:53:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104512.msg1144379@s{hash}msg1144379
@section 3 {tx}

  @p{««}Using bitcoind on a command-line? What operating system? @p{»»}

  @p{««}Something is stripping off the double-quotes from the "txid" and
  "vout" keys before it gets to bitcoind. If you're using bash on linux,
  then put single quotes around the arguments. Like this: @p{»»}

   @s{code}

  @p{««} I also corrected the second argument, the address is a string
  (strings in JSON are always "whatever") and the amount is decimal
  number-of-bitcoins. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1736}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-29 23:28:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104070.msg1144745@s{hash}msg1144745
@section 3 {tx}

  @p{««}Start here maybe: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}L262@p{link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1737}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-30 15:09:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104173.msg1146502@s{hash}msg1146502
@section 3 {tx}

  @s{quotedtext}

  @p{««}Solo miners, miners using p2pol, and mining pool operators will
  eventually have to upgrade. @p{»»}

  @p{««}RE: "Is there any web service to see the current ratio of v1 / v2?"
  @p{»»}

  @p{««}I bet if you ask nicely blockchain.info will create a page. I
  expect it to take a long time (a year or more) before 95% of the hashing
  power has upgraded and is producing v2 blocks. @p{»»}

  @p{««}The getblock RPC call will tell you a block's version number; if
  you're an old bash user like me then you can do something like: @p{»»}

  @s{code}
  
  @p{««}... to see the
  version numbers of the last 100 blocks (I see 2 of 100 right now). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1738}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-30 16:02:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104512.msg1146645@s{hash}msg1146645
@section 3 {tx}

  @p{««}Disclaimer: I don't do Windows. @p{»»}

  @p{««}But according to a quick google search, caret is the Windows
  cmd.exe escape character, @s{code} and {} are NOT special characters
  to cmd.exe. @p{»»}

  @p{««}So maybe this? @p{»»}

  @s{code} 

# ----------------------------------------------------------------------
@section 2 {ms1739}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-30 16:12:48 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104512.msg1146666@s{hash}msg1146666
@section 3 {tx}

  @p{««}mmm, no. @p{»»}

  @p{««}To be valid JSON, arg(1) must be: @p{»»}

  @s{code}

  @p{««} WTF is Windows doing with the arguments?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1740}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-30 22:18:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104630.msg1147697@s{hash}msg1147697
@section 3 {tx}

  @p{««}Please don't play this. @p{»»}

  @p{««}If it gets popular, then it is just "use the blockchain to create a
  Ponzi scheme". It can scale up, using new transactions to pay a little
  more to older transactions made 2 or 3 blocks ago. That's is the essence
  of a Ponzi scheme. @p{»»}

  @p{««}If you want to test something, use the testnet. That is what it is
  for. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1741}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-30 23:16:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104874.msg1147870@s{hash}msg1147870
@section 3 {tx}

  @p{««}Sweet! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1742}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-31 12:36:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104630.msg1149202@s{hash}msg1149202
@section 3 {tx}

  @p{««}Unless you can clearly explain, in small words that even I can
  understand, HOW you are getting the bitcoins to @p{(bf}pay@p{bf)}
  interest I'm going to assume that this is Yet Another Ponzi Scheme.
  @p{»»}

  @p{««}I understand how SatoshiDice makes money, and I have no issues with
  them generating lots of transactions. @p{»»}

  @p{««}If you were @p{(bf}CHARGING@p{bf)} interest then I would
  understand, and would have no issues with your service. @p{»»}

  @p{««}So: how will HungerCoins make money? And don't answer "I can't tell
  you or everybody else will do it," that is the Ponzi-operator's standard
  answer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1743}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-08-31 17:37:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104630.msg1149947@s{hash}msg1149947
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, I don't understand. @p{»»}

  @p{««}To whom are you lending the bitcoins you receive?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1744}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-01 14:29:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104630.msg1152183@s{hash}msg1152183
@section 3 {tx}

  @s{quotedtext}

  @p{««} How can Hunger Coin guarantee payback if you are lending the coins
  to people who may not pay YOU back? @p{»»}

  @p{««}I'm sorry, but "Hunger Invest" and "Hunger Lending" still sound
  like Ponzi schemes to me. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1745}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-01 15:49:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104630.msg1152365@s{hash}msg1152365
@section 3 {tx}

  @s{quotedtext}

  @p{««}You address it by explaining where the bitcoins come from for the
  'guaranteed' payouts. @p{»»}

  @p{««}Credit cards make money by charging merchants a fee, charging
  interest on late payments, etc. And they mitigate their risk by running
  credit reports on borrowers. @p{»»}

  @p{««}Legitimate lenders do something similar. @p{»»}

  @p{««}So, I'll ask again: what is your business model? How will you make
  the money to payback the people who are sending you X bitcoins and
  expecting to get X+Y back in a day? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1746}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-02 15:27:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105288.msg1154592@s{hash}msg1154592
@section 3 {tx}

  @p{««}I agree with Micon. I'm embarrassed by 'Long Term Offers' and
  scared by 'Securities'. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1747}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-02 15:56:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105288.msg1154646@s{hash}msg1154646
@section 3 {tx}

  @p{««}Securities scares me because in the USA there are strict laws with
  even TALKING about securities. @p{»»}

  @p{««}I know, I know, Congress is supposed to make no law abridging
  freedom of speech. I worry that won't stop the SEC from seizing the
  bitcointalk.org domain name for promoting unlicensed securities. @p{»»}

  @p{««}I think a separate top-level domain for everything under the
  Marketplace heading would be the right thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1748}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-02 16:13:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=80521.msg1154667@s{hash}msg1154667
@section 3 {tx}

  @p{««}Does valgrind really not work on Mountain Lion? Good reason for me
  not to upgrade... (runs great on Snow Leopard). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1749}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-02 22:14:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89122.msg1155358@s{hash}msg1155358
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yeah, don't do that, you'll annoy some of us moderators. @p{»»}

  @p{««}I think Micon is doing the moral thing, warning people of what he
  thinks are scams. @p{»»}

  @p{««}I think they're scams, too. It is impossible to get risk-free 1.5%
  weekly interest, I don't care how good you are at "playing the market"
  or "choosing who to lend to." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1750}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-02 23:38:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105524.msg1155491@s{hash}msg1155491
@section 3 {tx}

  @p{««}I was sent a personal message by somebody saying that the burden of
  proof that something is a scam should be on the person accusing the
  scammer. If they can't @p{(bf}PROVE@p{bf)} it, then they should shut up.
  @p{»»}

  @p{««}I disagree. I think the burden of proof is on people "guaranteeing"
  high returns. @p{»»}

  @p{««}Here's how I think of it: @p{»»}

  @p{««}Imagine you see somebody claiming they have invented a perpetual
  motion machine. @p{»»}

  @p{««}You claim bullshit, because that's against the laws of physics and
  all previous experience. @p{»»}

  @p{««}Now they send you an email, saying "... before making such
  accusations you need to @p{(bf}PROVE@p{bf)} that it cannot work." @p{»»}

  @p{««}Foolproof schemes to make high interest at low risk are the
  financial world's perpetual motion machines. They do not exist. @p{»»}

  @p{««}Perpetual motion machines may not be scams; there are misguided
  people who really do believe that they've violated the laws of physics
  and will prove all of those pesky scientists wrong. I'm sure there are
  people who truly believe that they've invented foolproof methods of
  investing lots of money with no risk, too, but I'm equally sure they're
  delusional. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1751}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-03 13:56:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105505.msg1156757@s{hash}msg1156757
@section 3 {tx}

  @p{««}Bug. I never tested the combination of signing a pay-to-script-hash
  transaction with non-wallet private keys. @p{»»}

  @p{««}I'm not 100% sure how to fix it, though. The problem is private
  keys, public keys, and P2SH scripts are all stored in a "keystore." When
  you give the third argument to signrawtransaction, it creates a keystore
  that contains just the private keys (and the corresponding public keys)
  that you give, and uses that to sign the transaction. @p{»»}

  @p{««}There's currently no way to give it the P2SH script that
  corresponds to 34y6HmY6zTH51KTC9vd36HasNL4kLKcisC, but the transaction
  signing code needs that information. @p{»»}

  @p{««}I think the right fix is to give signrawtransaction both the
  private key(s) and any P2SH information needed... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1752}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-04 13:36:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105505.msg1159063@s{hash}msg1159063
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm leaning towards extending the 2nd argument, to give previous
  inputs and, if the previous inputs are P2SH, previous inputs scripts.
  @p{»»}

  @p{««}Along with a new 'rawmultisigaddress' that is just like
  addmultisigaddress, but doesn't add the redemption script to the wallet
  but instead returns it. @p{»»}

  @s{quotedtext}

  @p{««}addmultisigaddress added the P2SH scripts to the wallet. @p{»»}

  @p{««}RE: when can you expect a fix: @p{»»}

  @p{««}It is too late to add new RPC features to the 0.7 release, so no
  fix until the next release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1753}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-04 19:02:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105657.msg1159835@s{hash}msg1159835
@section 3 {tx}

  @p{««}I'd like bitcointalk.@p{(bf}org@p{bf)} to be in the spirit of the
  Internet's original ".org" @p{--} For Non-Commercial Use Only. @p{»»}

  @p{««}But... it is hard to figure out what is Commercial Use and what
  isn't (e.g. some mining pools are non-profit, some for-profit, and I'm
  sure there are some in the fuzzy middle), which is why there really
  aren't any rules for .org any more. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1754}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-04 19:58:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105756.msg1159999@s{hash}msg1159999
@section 3 {tx}

  @p{««}From @p{(link}"Operator Imprecision and Scaling of Shor's
  Algorithm" (2008)@p{link)}: @p{»»}

  @s{quotedtext}

  @p{««}I don't see any published rebuttals in a quick Google Scholar
  search. Maybe there will be a breakthrough (or already has been... any
  QC wizards listening here?) in handling the fuzziness of quantum
  calculations as you scale up the number of qbits, but 256-bit ECDSA
  looks pretty darn secure to me right now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1755}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-05 17:13:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40264.msg1162402@s{hash}msg1162402
@section 3 {tx}

  @p{««}Yes, please don't create lots of unspendable scriptPubKeys. There
  are more prunable ways of embedding messages into transactions. And
  there are even better ways of associating messages with transactions, so
  only people involved with the transaction can read the message (if
  that's desired). @p{»»}

  @p{««}In other words, lets figure out how to do this the right way. The
  way you're doing it now will stop working as soon as the network
  upgrades anyway (0-value outputs are nonstandard as of the 0.7 release).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1756}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-05 18:03:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101011.msg1162505@s{hash}msg1162505
@section 3 {tx}

  @s{quotedtext}

  @p{««}You're missing the point of Bitcoin if you feel left out. You can
  be as involved as you want to be, just go make something happen@p{--}
  find something you think needs doing, recruit some people to help if you
  need help, and do it. Are you waiting for an invitation or permission
  from somebody? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1757}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 02:28:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106089.msg1163656@s{hash}msg1163656
@section 3 {tx}

  @s{quotedtext}

  @p{««} I've said that I think the
  download-and-install-software-on-your-PC is a mostly-dead way of using
  software, and that the vast majority of people using Bitcoin in a year
  or three will be using it via a web application or on their smart phone.
  That's half of the reason why I don't think improving the UI is a high
  priority right now (the other half is because I think solving wallet
  security and backup issues is critical). @p{»»}

  @p{««}RE: 2112 and GAAP: "patches welcome." I don't know nuthin about
  GAAP, so if you're complaining that the reference implementation doesn't
  adhere to them then I'm not surprised. Feel free to fix that, or write a
  detailed proposal on what's wrong, why it'll cause problems, and how it
  ought to be fixed. @p{»»}

  @p{««}RE: funding development: funding open source software projects is
  tricky; if done poorly you end up with a couple of paid developers and
  lots of disappointed unpaid former contributors who decide "I'm not
  gonna work if I'm not gonna get paid." @p{»»}

  @p{««}That said... stay tuned, and I'll say more when I can. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1758}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 02:42:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101011.msg1163680@s{hash}msg1163680
@section 3 {tx}

  @s{quotedtext}

  @p{««} "Hey, I've got this fantastic idea!" @p{»»}

  @p{««}"Really! Tell me all about it!" @p{»»}

  @p{««}"We're going to blah blah blah." @p{»»}

  @p{««}"Uhh... did you talk to a lawyer about that? That might be
  illegal." @p{»»}

  @p{««}"Uhh... really? no." @p{»»}

  @p{««}"And where will you get the money to do it?" @p{»»}

  @p{««}"Uhhh... haven't figured that out yet." @p{»»}

  @p{««}"And if I want to participate, what should I do?" @p{»»}

  @p{««}"Uhh... I dunno, we don't really have a process for that yet..."
  @p{»»}

  @p{««}I made the mistake of asking a reporter when her deadline was,
  because if it was far enough away I could tell her about the neat idea.
  I should have kept my mouth shut or sworn her to secrecy. @p{»»}

  @p{««}Announcing a half-baked idea is counterproductive; you'll just get
  a gazillion questions that you can't answer, or, even worse, people will
  assume they know the answers and then be disappointed when it turns out
  the idea they thought they heard you describe isn't the same idea they
  thought they heard. @p{»»}

  @p{««}Announcing a fully-baked idea and then modifying it based on what
  everybody thinks and how it works out in practice is the right way to do
  things, in my humble opinion. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1759}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 16:01:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106026.msg1164968@s{hash}msg1164968
@section 3 {tx}

  @p{««}Sergio: @p{»»}

  @p{««}Is a new type of message necessary? @p{»»}

  @p{««}How about just making the transaction relay rules: @p{»»}

  @p{««}1) If the transaction has inputs that conflict with one already in
  the best blockchain, drop it. @p{brk} 2) If the transaction has inputs
  that conflict with another transaction in the memory pool, and it is the
  first such conflicting transaction, check the new transaction's
  signatures and if they're OK mark the memory pool transaction as "saw a
  double spend". Then relay the conflicting transaction (but don't
  otherwise remember it). @p{»»}

  @p{««}Rule (1) is to prevent an attacker from taking a bunch of her old,
  already-in-the-blockchain outputs and trying to generate a "double spend
  alert storm" by sending bogus double-spend attempts for them. @p{»»}

  @p{««}Rule (2) is to limit the amount of network traffic / signature
  checks an attacker can create to be twice what they can generate today
  (attackers can, and do, try to flood the network with transactions, but
  transaction fees and the free transaction relay policy keeps them in
  check). @p{»»}

  @p{««}The GUI/RPC should definitely show attempted-double-spend memory
  pool (0-conf) transactions as "BEWARE". @p{»»}

  @p{««}I think those rules will flood the network with the double-spend
  attempt, alerting merchants/users that something odd is happening.
  Without making it possible for an attacker to get the network flooded
  with gazillions of double-spend alert messages. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1760}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 16:32:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106026.msg1165058@s{hash}msg1165058
@section 3 {tx}

  @p{««}Right, you do have to remember them for at least a little while...
  Replace "relay but don't remember" with "relay and forget as soon as
  possible." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1761}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 19:59:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106236.msg1165551@s{hash}msg1165551
@section 3 {tx}

  @p{««}Bitcoin version 0.7.0 release candidate 3 is now available for
  download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Unless another critical bug is found, this should be the final
  0.7.0 release. @p{»»}

  @p{««}How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you were running on Linux with a version that might have been
  compiled @p{brk} with a different version of Berkeley DB (for example,
  if you were using an @p{brk} Ubuntu PPA version), then run the old
  version again with the -detachdb @p{brk} argument and shut it down; if
  you do not, then the new version will not @p{brk} be able to read the
  database files and will exit with an error. @p{»»}

  @p{««}Incompatible Changes @p{brk} * Replaced the 'getmemorypool' RPC command with
  'getblocktemplate/submitblock' @p{»»}

    @p{(li}and 'getrawmempool' commands. @p{li)} * Remove deprecated RPC
  'getblocknumber' @p{»»}

  @p{««}Bitcoin Improvement Proposals implemented 
  @p{brk} BIP 22 - 'getblocktemplate', 'submitblock' RPCs @p{brk} BIP 34 -
  block version 2, height in coinbase @p{brk} BIP 35 - 'mempool' message,
  extended 'getdata' message behavior @p{»»}

  @p{««} Core bitcoin handling and blockchain database 
  @p{brk} * Reduced CPU usage, by eliminating some redundant hash
  calculations @p{brk} * Cache signature verifications, to eliminate
  redundant signature checks @p{brk} * Transactions with zero-value
  outputs are considered non-standard @p{brk} * Mining: when creating new
  blocks, sort 'paid' area by fee-per-kb @p{brk} * Database: better
  validation of on-disk stored data @p{brk} * Database: minor
  optimizations and reliability improvements @p{brk} * -loadblock=FILE
  will import an external block file @p{brk} * Additional DoS
  (denial-of-service) prevention measures @p{brk} * New blockchain
  checkpoint at block 193,000 @p{»»}

  @p{««} JSON-RPC API @p{brk} @p{brk} * Internal HTTP server is now thread-per-connection, rather than
  @p{»»}

    @p{(li}a single-threaded queue that would stall on network I/O.
  @p{li)} * Internal HTTP server supports HTTP/1.1, pipelined requests and
  @p{»»}

    @p{(li}connection keep-alive. @p{li)} * Support JSON-RPC 2.0 batches,
  to encapsulate multiple JSON-RPC requests @p{»»}

    @p{(li}within a single HTTP request. @p{li)} * IPv6 support @p{brk} *
  Added raw transaction API. See @s{(link)} @p{brk} * Added
  'getrawmempool', to list contents of TX memory pool @p{brk} * Added
  'getpeerinfo', to list data about each connected network peer @p{brk} *
  Added 'listaddressgroupings' for better coin control @p{brk} * Rework
  gettransaction, getblock calls. 'gettransaction' responds for @p{»»}

    @p{(li}non-wallet TXs now. @p{li)} * Remove deprecated RPC
  'getblocknumber' @p{brk} * Remove superceded RPC 'getmemorypool' (see
  BIP 22, above) @p{brk} * listtransactions output now displays "smart"
  times for transactions, @p{»»}

    @p{(li}and 'blocktime' and 'timereceived' fields were added @p{li)}

  @p{««} P2P networking  @p{brk} * IPv6
  support @p{brk} * Tor hidden service support (see doc/Tor.txt) @p{brk} *
  Attempts to fix "stuck blockchain download" problems @p{brk} * Replace
  BDB database "addr.dat" with internally-managed "peers.dat" @p{»»}

    @p{(li}file containing peer address data. @p{li)} * Lower default send
  buffer from 10MB to 1MB @p{brk} * proxy: SOCKS5 by default @p{brk} *
  Support connecting by hostnames passed to proxy @p{brk} * Add -seednode
  connections, and use this instead of DNS seeds when proxied @p{brk} *
  Added -externalip and -discover @p{brk} * Add -onlynet to connect only
  to a given network (IPv4, IPv6, or Tor) @p{brk} * Separate listening
  sockets, -bind=@p{lt}addr@s{gt} @p{»»}

  @p{««} Qt GUI @p{brk} * Add UI RPC console
  / debug window @p{brk} * Re-Enable URI handling on Windows, add safety
  checks and tray-notifications @p{brk} * Harmonize the use of ellipsis
  ("...") to be used in menus, but not on buttons @p{brk} * Add 2 labels
  to the overviewpage that display Wallet and Transaction status (obsolete
  or current) @p{brk} * Extend the optionsdialog (e.g. language selection)
  and re-work it to a tabbed UI @p{brk} * Merge sign/verify message into a
  single window with tabbed UI @p{brk} * Ensure a changed bitcoin unit
  immediately updates all GUI elements that use units @p{brk} * Update QR
  Code dialog @p{brk} * Improve error reporting at startup @p{brk} *
  Fine-grained UI updates for a much smoother UI during block downloads
  @p{brk} * Remove autocorrection of 0/i in addresses in UI @p{brk} *
  Reorganize tray icon menu into more logical order @p{brk} * Persistently
  poll for balance change when number of blocks changed @p{brk} * Much
  better translations @p{brk} * Override progress bar design on platforms
  with segmented progress bars to assist with readability @p{brk} * Added
  'immature balance' display on the overview page @p{brk} * (Windows
  only): enable ASLR and DEP for bitcoin-qt.exe @p{brk} * (Windows only):
  add meta-data to bitcoin-qt.exe (e.g. description) @p{»»}

  @p{««}Internal codebase  @p{brk} *
  Additional unit tests @p{brk} * Compile warning fixes @p{»»}

  @p{««} Miscellaneous  @p{brk} * Reopen debug.log
  upon SIGHUP @p{brk} * Bash programmable completion for bitcoind(1)
  @p{brk} * On supported OS's, each thread is given a useful name @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1762}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-06 22:12:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106026.msg1165899@s{hash}msg1165899
@section 3 {tx}

  @s{quotedtext}

  @p{««}Good point. I assume that miners will choose to mine the version of
  a transaction with the highest fee-per-kilobyte, since that will give
  them the best profit, but actually changing the code to implement that
  policy has been controversial when I've brought it up before. @p{»»}

  @p{««}To fight transaction spam, I think the relaying logic will need to
  get smarter, too. A large, expensive-to-verify double-spend should be
  way down on the "stuff that should be relayed when there is enough
  bandwidth" list. @p{»»}

  @s{quotedtext}

  @p{««} That's a different issue, and a new feature. I think the best way
  to implement that feature is "child pays for parent" (see @s{(link)} for
  a proposed implementation), and then the user can broadcast a high-fee
  pay-to-self child transaction to get the parent accepted into a block.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1763}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 02:20:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106266.msg1166442@s{hash}msg1166442
@section 3 {tx}

  @p{««}First: I think it is extremely unlikely that somebody would spend a
  million dollars on an attack that takes months to pull off, doesn't
  benefit the attacker at all, is easy to fix, and that would be easy for
  the network to recover from. @p{»»}

  @s{quotedtext}

  @p{««}Good idea, and easy to do. @p{»»}

  @p{««}I've got a half-finished "user-defined checkpoint" patch in my
  personal git tree, so users, merchants, and big mining pools can decide
  for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC
  command) to protect against this type of attack. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1764}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 14:08:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106026.msg1167664@s{hash}msg1167664
@section 3 {tx}

  @p{««}What stops an attacker from pre-generating tens or hundreds of
  thousands of alert messages (for tens or hundreds of thousands of their
  own transactions that the previously put into the chain) and then
  sending them to the network all at once? @p{»»}

  @p{««}Goal would be to keep the network busy checking the alert
  signatures.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1765}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 14:17:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106266.msg1167680@s{hash}msg1167680
@section 3 {tx}

  @s{quotedtext}

  @p{««}No. Absolutely not. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1766}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 17:58:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89122.msg1168136@s{hash}msg1168136
@section 3 {tx}

  @p{««}Fraud is telling people lies to get them to do something or making
  promises you know you can't keep. @p{»»}

  @p{««}In my humble opinion, promising people "Risk-free" returns is
  fraud. Even US Treasury Bills are not "risk free." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1767}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 21:52:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106236.msg1168820@s{hash}msg1168820
@section 3 {tx}

  @s{quotedtext}

  @p{««}Anybody else having success or failure running rc2 on Windows 7,
  please let us know... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1768}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-07 23:32:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106441.msg1169086@s{hash}msg1169086
@section 3 {tx}

  @p{««}See @s{(link)} for recent research on passphrase usability; results
  do not look good. @s{(link)} to see what other researchers have
  tried.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1769}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-08 15:22:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106162.msg1170703@s{hash}msg1170703
@section 3 {tx}

  @s{quotedtext}

  @p{««}That would violate his users' privacy; maybe I don't want you (or
  the rest of the world) to know that I have a Gox account. @p{»»}

  @p{««}You don't need accounts or registration, you just need a two-step
  process: @p{»»}

  @p{««}1) User tells you their refund address @p{brk} 2) You give the user
  a unique deposit address, and link the refund and deposit addresses in
  your database. @p{»»}

  @p{««}To avoid creating a gazillion deposit addresses or bothering the
  user to give you a refund address every time, you might want to store
  the "user already got a deposit address" flag in a session cookie. But
  if the user will remember the deposit address then even that isn't
  necessary. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1770}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-08 17:09:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106461.msg1170942@s{hash}msg1170942
@section 3 {tx}

  @p{««}We should avoid saying "canonical" @p{--} I just peeked at the
  ASN.1/BER/DER spec, and there's a "canonical" encoding that is different
  from the "distinguished" encoding: @p{»»}

  @p{««} @s{(link)} @p{»»}

  @p{««}(international standards committees seem to be completely incapable
  of adhering to the Keep It Simple, Stupid principle). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1771}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-08 17:20:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=120753.msg1170970@s{hash}msg1170970
@section 3 {tx}

  @s{quotedtext}

  @p{««}When I hear that, I hear "you should stop doing what you're doing
  for a year or two or three and re-implement the whole thing." @p{»»}

  @p{««}Yeah... no. As much as that would be a fun project, I don't think
  that is the job of the team working on the existing reference
  implementation. Keeping the existing software and network running as
  smoothly as possible is the highest priority. @p{»»}

  @p{««}Another very high priority is working through issues that arise as
  alternative implementations happen (see the current thread in the
  development section about non-DER-encoded signatures for a good
  example). An alternative implementation that has the kind of accounting
  that you want is a great idea@p{--} go do it, fund it, or convince
  somebody else to do it. I think genjix' libbitcoin has the "store the
  blockchain in a database" that you want (although last I heard he was
  running into performance issues with that approach). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1772}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-09 16:03:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=107197.msg1173938@s{hash}msg1173938
@section 3 {tx}

  @p{««}Old coins are preferred over new coins because transaction spammers
  spend coins over-and-over again quickly to try to flood the network with
  transactions. @p{»»}

  @p{««}Unintentional transaction spammers (like people playing SatoshiDice
  over and over) accidentally do the same thing, so their transactions are
  given low priority and can take a long time to get confirmed. @p{»»}

  @p{««}Maybe think of it this way: @p{»»}

  @p{(li}  Transaction fees are to pay miners to include your transactions.
   @p{li)}

    @p{(li}@p{(li} Transaction priority is used to "pay" for the network
    bandwith used by free transactions (note that any node relaying or
    listening for transactions pays the cost of every extra transaction).
    @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1773}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 00:22:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=107180.msg1175847@s{hash}msg1175847
@section 3 {tx}

  @p{««}We need a payment protocol with non-repudiation built in. @p{»»}

  @p{««}See @s{(link)} for a multisig version (the singlesig version is
  simpler, but the merchant @p{lt}-@s{gt} customer communication will be
  the same). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1774}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 12:56:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106236.msg1177457@s{hash}msg1177457
@section 3 {tx}

  @s{quotedtext}

  @p{««} debug.log might tell you why it is being rejected. Some reasons it
  might be rejected: @p{»»}

  @p{(li}  You're re-using an input that has already been spent.  @p{li)}

    @p{(li}@p{(li} Sum(outputs) is greater than Sum(inputs) @p{li)}
    @p{(li} signrawtransaction was unable to sign all of the inputs (it
    did not report "complete" : true ) @p{li)}

  @p{««}By the way: be EXTREMELY careful with the raw transactions API. You
  can easily forget to include a change output and create transactions
  with huge fees; test your code thoroughly on testnet before putting it
  into production. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1775}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 13:58:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105505.msg1177579@s{hash}msg1177579
@section 3 {tx}

  @p{««}I just submitted a pull request to fix this: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1776}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 17:39:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106236.msg1178156@s{hash}msg1178156
@section 3 {tx}

  @p{««}Consensus is the RPC-doesn't-work-if-you-disable-IpV6 bug is
  serious enough to hold up the 0.7.0 final release. @p{»»}

  @p{««}So the plan will be: get a fix for that bug and release/test a
  0.7.0rc3. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1777}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 18:25:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=108423.msg1178327@s{hash}msg1178327
@section 3 {tx}

  @p{««}Hoisted from the comments on @p{(link}pull request 1809:@p{link)}
  @p{»»}

  @s{quotedtext}

  @p{««} I think there are definitely use-cases for associating some
  @p{(bf}immutable@p{bf)} meta-data with a transaction. Example: a bitcoin
  client that gave a unique refund address for every outgoing transaction,
  and automatically groups refund transactions together with the original
  payment transactions. @p{»»}

  @p{««}Somebody could create a service that associates data with
  transaction ids, but they need to do more work to make the data
  immutable... and it is not clear to me how you make that secure. @p{»»}

  @p{««}I really want my refund address to be 'baked in' to the transaction
  that I sign, so if the transaction is accepted into the block chain I
  know there hasn't been some hacker somewhere who managed to rewrite the
  refund address so they get my coins. @p{»»}

  @p{««}If I'm doing some type of smart contract with bitcoin transactions,
  I want the contract data baked in and covered by the transaction
  signature. And the person I'm transacting with would like to be sure I
  can't change the terms of the contract once the transaction is signed.
  @p{»»}

  @p{««}It seems to me the simplest, most straightforward, and secure way
  to do that is with a limited-data OP_DROP transaction type. The data in
  the blockchain is (transaction+HASH(metadata)), and that is what is
  signed. The actual metadata can be stored outside the blockchain and
  looked up (and verified) by hash (hand-wave, hand-wave, I have no idea
  how that happens, if there is more than one place that stores
  transaction metadata, etc). @p{»»}

  @p{««}Any scheme that tries to move the HASH(metadata) outside the
  transaction signature recorded in the blockchain will, at the very
  least, be more complicated. And, therefore, very likely to be less
  secure. @p{»»}

  @p{««}Am I missing some other simple, secure, decentralized,
  non-blockchain scheme for attaching metadata to transactions? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1778}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-10 20:34:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=108423.msg1178824@s{hash}msg1178824
@section 3 {tx}

  @p{««}Productive discussion in IRC today: @p{»»}

    @p{(li} @p{(link}@s{(link)}@s{hash}l4463724@p{link)} @p{li)}

  @p{««}Executive summary: Good idea, Stefan. Lots of details to be worked
  out... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1779}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-11 22:21:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=107074.msg1182935@s{hash}msg1182935
@section 3 {tx}

  @p{««}You would have probably found that a lot quicker running a testnet
  version. @p{»»}

  @p{««}The testnet Faucet is giving away 500 play bitcoins at a time right
  now: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1780}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-12 20:25:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=104070.msg1185693@s{hash}msg1185693
@section 3 {tx}

  @p{««}BCDataStream.write takes binary data, so add a .decode('hex_codec')
  to the big long hex string: @p{»»}

  @s{code}

# ----------------------------------------------------------------------
@section 2 {ms1781}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-13 18:42:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=106236.msg1188354@s{hash}msg1188354
@section 3 {tx}

  @p{««}Release candidate 3 binaries are up; major differences from rc2
  are: @p{»»}

  @p{««}1) Fix the IPv6 RPC problem (you will get a warning in debug.log,
  that is expected) @p{brk} 2) Updated translations @p{»»}


  @p{««}We could use more people "gitian building" releases; if you have a
  machine with at least 3 gig of memory and 20 gig of disk space, you can
  now help reproduce the builds using LXC running inside something like
  VirtualBox: @p{»»}

    @p{(li}@p{(link}@s{(link)}@s{hash}L57@p{link)} 

# ----------------------------------------------------------------------
@section 2 {ms1782}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-14 01:58:18 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=91183.msg1189394@s{hash}msg1189394
@section 3 {tx}

  @p{««}Is Decrits meant to be a decentralized solution? @p{»»}

  @p{««}How is the coin minting queue managed? E.g. you say "Once enough
  minters have joined the queue..." : what if there is disagreement about
  which miners are in the queue or if there are "enough"? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1783}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-14 02:08:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=109264.msg1189414@s{hash}msg1189414
@section 3 {tx}

  @p{««}Yeah, not Satoshi. Satoshi has red hair and a big handlebar
  moustache. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1784}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-14 16:47:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40264.msg1190891@s{hash}msg1190891
@section 3 {tx}

  @s{quotedtext}

  @p{««}Two-people-required-to-spend bitcoin addresses would be a great
  feature for blockchain.info. @p{»»}

  @p{««}Coins would be sent to that address, then both address owners would
  have to agree to spend them (by signing transactions). @p{»»}

  @p{««}The incoming coins @p{(bf}do@p{bf)} have to be fully spent, but it
  is easy to create transactions that send the change back into the
  "vault" (multisig address). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1785}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-14 18:35:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=109467.msg1191162@s{hash}msg1191162
@section 3 {tx}

  @p{««}Right now, there is a hard-coded limit of 1 megabyte per block.
  @p{»»}

  @p{««}If we assume that limit never changes, that gives: @p{brk} 1MB per
   block * 6 blocks per hour * 24*365.25*200 = 10,519,200 MB @p{»»}

  @p{««}... or 10.5 terabytes for the maximum size of the entire blockchain
  over the next 200 years (somebody check my math, I'm really good at
  dropping zeroes). @p{»»}

  @p{««}I expect that in 200 years 10 terabytes of storage will cost a few
  pennies. @p{»»}

  @p{««} @p{hrule} Now whether or not that 1 megabyte per block limit
  should go away is hotly debated, and will be debated more and more as
  transaction volume increases.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1786}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-17 15:23:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110136.msg1198126@s{hash}msg1198126
@section 3 {tx}

  @p{««}If you're running Bitcoin-Qt on a Mac, what version of OSX are you
  running? @p{»»}

  @p{««}I'm trying to get an idea of how many people are still running
  10.5, because supporting that version of OSX is starting to become
  painful (it is almost 5 years old now...). @p{»»}

  @p{««}And before somebody asks: yes, signing the Bitcoin-Qt app so it
  plays nicely with 10.8's "@p{(link}Gatekeeper@p{link)}" is near the top
  of the TODO list. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1787}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-17 20:18:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110182.msg1198913@s{hash}msg1198913
@section 3 {tx}

  @p{««}You request a transaction by hash (using an 'inv' message). @p{»»}

  @p{««}You then get the transaction in a 'tx' message. The hash isn't sent
  as part of that data, because you can reconstruct it by hashing the
  transaction data. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1788}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-17 23:50:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110243.msg1199467@s{hash}msg1199467
@section 3 {tx}

  @p{««}Bitcoin version 0.7.0 is now available for download at: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}We recommend that everybody running prior versions of
  bitcoind/Bitcoin-Qt @p{brk} upgrade to this release, @p{(it}except for
  users running Mac OSX 10.5@p{it)}. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Project source code is hosted at github; you can get @p{brk}
  source-only tarballs/zipballs directly from there: @p{»»}

    @p{(li}@s{(link)} @s{hash} .tar.gz @p{li)}

    @p{(li}@s{(link)} @s{hash} .zip @p{li)}

  @p{««}Ubuntu Linux users can use the "Personal Package Archive" (PPA)
  @p{brk} maintained by Matt Corallo to automatically keep @p{brk} bitcoin
  up-to-date. Just type @p{»»}

    @p{(li}sudo apt-add-repository ppa:bitcoin/bitcoin @p{li)}

    @p{(li}sudo apt-get update @p{li)} in your terminal, then install the
  bitcoin-qt package: @p{»»}

    @p{(li}sudo apt-get install bitcoin-qt @p{li)}

  @p{««} @p{(ul}How to Upgrade@p{??)} @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{»»}

  @s{code}

  @p{««}If you were running on Linux with a version that might have been
  compiled @p{brk} with a different version of Berkeley DB (for example,
  if you were using the @p{brk} PPA and are switching to the binary
  release), then run the old version again @p{brk} with the -detachdb
  argument and shut it down; if you do not, then the new @p{brk} version
  will not be able to read the database files and will exit with an error.
  @p{»»}

  @p{««}@p{(ul}Incompatible Changes@p{??)} @p{»»}

  @p{««}* Replaced the 'getmemorypool' RPC command with
  'getblocktemplate/submitblock' @p{»»}

    @p{(li}and 'getrawmempool' commands. @p{li)} * Remove deprecated RPC
  'getblocknumber' @p{»»}

  @p{««}@p{(ul}Bitcoin Improvement Proposals implemented@p{??)} @p{»»}

  @p{««}BIP 22 - 'getblocktemplate', 'submitblock' RPCs @p{brk} BIP 34 -
  block version 2, height in coinbase @p{brk} BIP 35 - 'mempool' message,
  extended 'getdata' message behavior @p{»»}

  @p{««} @p{(ul}Core bitcoin handling and blockchain database@p{??)} @p{»»}

  @p{««}* Reduced CPU usage, by eliminating some redundant hash
  calculations @p{brk} * Cache signature verifications, to eliminate
  redundant signature checks @p{brk} * Transactions with zero-value
  outputs are considered non-standard @p{brk} * Mining: when creating new
  blocks, sort 'paid' area by fee-per-kb @p{brk} * Database: better
  validation of on-disk stored data @p{brk} * Database: minor
  optimizations and reliability improvements @p{brk} * -loadblock=FILE
  will import an external block file @p{brk} * Additional DoS
  (denial-of-service) prevention measures @p{brk} * New blockchain
  checkpoint at block 193,000 @p{»»}

  @p{««} @p{(ul}JSON-RPC API@p{??)} @p{»»}

  @p{««}* Internal HTTP server is now thread-per-connection, rather than
  @p{»»}

    @p{(li}a single-threaded queue that would stall on network I/O.
  @p{li)} * Internal HTTP server supports HTTP/1.1, pipelined requests and
  @p{»»}

    @p{(li}connection keep-alive. @p{li)} * Support JSON-RPC 2.0 batches,
  to encapsulate multiple JSON-RPC requests @p{»»}

    @p{(li}within a single HTTP request. @p{li)} * IPv6 support @p{brk} *
  Added raw transaction API. See @s{(link)} @p{brk} * Added
  'getrawmempool', to list contents of TX memory pool @p{brk} * Added
  'getpeerinfo', to list data about each connected network peer @p{brk} *
  Added 'listaddressgroupings' for better coin control @p{brk} * Rework
  getblock call. @p{brk} * Remove deprecated RPC 'getblocknumber' @p{brk}
  * Remove superceded RPC 'getmemorypool' (see BIP 22, above) @p{brk} *
  listtransactions output now displays "smart" times for transactions,
  @p{»»}

    @p{(li}and 'blocktime' and 'timereceived' fields were added @p{li)}

  @p{««} @p{(ul}P2P networking@p{??)} @p{»»}

  @p{««}* IPv6 support @p{brk} * Tor hidden service support (see
  doc/Tor.txt) @p{brk} * Attempts to fix "stuck blockchain download"
  problems @p{brk} * Replace BDB database "addr.dat" with
  internally-managed "peers.dat" @p{»»}

    @p{(li}file containing peer address data. @p{li)} * Lower default send
  buffer from 10MB to 1MB @p{brk} * proxy: SOCKS5 by default @p{brk} *
  Support connecting by hostnames passed to proxy @p{brk} * Add -seednode
  connections, and use this instead of DNS seeds when proxied @p{brk} *
  Added -externalip and -discover @p{brk} * Add -onlynet to connect only
  to a given network (IPv4, IPv6, or Tor) @p{brk} * Separate listening
  sockets, -bind=@p{lt}addr@s{gt} @p{»»}

  @p{««} @p{(ul}Qt GUI@p{??)} @p{»»}

  @p{««}* Add UI RPC console / debug window @p{brk} * Re-Enable URI
  handling on Windows, add safety checks and tray-notifications @p{brk} *
  Harmonize the use of ellipsis ("...") to be used in menus, but not on
  buttons @p{brk} * Add 2 labels to the overviewpage that display Wallet
  and Transaction status (obsolete or current) @p{brk} * Extend the
  optionsdialog (e.g. language selection) and re-work it to a tabbed UI
  @p{brk} * Merge sign/verify message into a single window with tabbed UI
  @p{brk} * Ensure a changed bitcoin unit immediately updates all GUI
  elements that use units @p{brk} * Update QR Code dialog @p{brk} *
  Improve error reporting at startup @p{brk} * Fine-grained UI updates for
  a much smoother UI during block downloads @p{brk} * Remove
  autocorrection of 0/i in addresses in UI @p{brk} * Reorganize tray icon
  menu into more logical order @p{brk} * Persistently poll for balance
  change when number of blocks changed @p{brk} * Much better translations
  @p{brk} * Override progress bar design on platforms with segmented
  progress bars to assist with readability @p{brk} * Added 'immature
  balance' display on the overview page @p{brk} * (Windows only): enable
  ASLR and DEP for bitcoin-qt.exe @p{brk} * (Windows only): add meta-data
  to bitcoin-qt.exe (e.g. description) @p{»»}

  @p{««}@p{(ul}Internal codebase@p{??)} @p{»»}

  @p{««}* Additional unit tests @p{brk} * Compile warning fixes @p{»»}

  @p{««} @p{(ul}Miscellaneous@p{??)} @p{»»}

  @p{««}* Reopen debug.log upon SIGHUP @p{brk} * Bash programmable
  completion for bitcoind(1) @p{brk} * On supported OS's, each thread is
  given a useful name @p{»»}

  @p{««} @p{hrule} @p{brk} Thanks to everybody who contributed to this
  release: @p{»»}

  @p{««}Chris Moore @p{brk} Christian von Roques @p{brk} David Joel
  Schwartz @p{brk} Douglas Huff @p{brk} Fordy @p{brk} Gavin Andresen
  @p{brk} Giel van Schijndel @p{brk} Gregory Maxwell @p{brk} Jeff Garzik
  @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk}
  Michael Hendricks @p{brk} Peter Todd @p{brk} Philip Kaufmann @p{brk}
  Pieter Wuille @p{brk} R E Broadley @p{brk} Ricardo M. Correia @p{brk}
  Rune K. Svendsen @p{brk} Scott Ellis @p{brk} Stephane Glondu @p{brk}
  Wladimir J. van der Laan @p{brk} cardpuncher @p{brk} coderrr @p{brk}
  fanquake @p{brk} grimd34th @p{brk} sje397 @p{brk} xanatos @p{»»}

  @p{««}Thanks to Sergio Lerner for reporting denial-of-service
  vulnerabilities fixed in this release.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1789}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-18 00:33:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110244.msg1199575@s{hash}msg1199575
@section 3 {tx}

  @p{««}Yes, mathematically approximately zilch. @p{»»}

  @p{««}... unless the OpenSSL entropy-gathering code on your computer
  isn't working properly, so bitcoin's random-key-generating code doesn't
  work (we use OpenSSL to get good random numbers). That is a bigger
  worry, but happily lots of people have been reviewing that code for
  years.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1790}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-18 03:25:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110267.msg1199947@s{hash}msg1199947
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, if by earlier you mean a few minutes earlier (it would have to
  have a 50+ BTC fee to make it worthwhile for miners to double-spend a
  transaction that already made it into the last block). @p{»»}

  @p{««}Two zero-confirmation transactions essentially happen at the same
  time as far as the network is concerned; if there was a good way for
  everybody to agree that they happened in a particular order we wouldn't
  need the blockchain. I assume that miners will take the transactions
  that give them the greatest short-term profit; that may not be correct
  (there might be a lot of miners interested in the long-term health of
  Bitcoin), but I think it is the safest assumption. And I think if we
  design payment protocols around that assumption they will be more
  secure. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1791}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-18 13:10:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110243.msg1200808@s{hash}msg1200808
@section 3 {tx}

  @p{««}The block files (blk000N.dat) are not BDB files, they're a raw,
  binary, append-only list of serialized blocks, so -loadblock doesn't
  care about the version of libdb used. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1792}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-18 13:11:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110346.msg1200810@s{hash}msg1200810
@section 3 {tx}

  @p{««}Sure, use multisig and store the keys on two different types of
  hardware (e.g. cell phone and computer). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1793}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-18 13:50:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=108987.msg1200889@s{hash}msg1200889
@section 3 {tx}

  @p{««}RE: listing bitcoind separately on the clients page: good idea.
  casascius, do you know (or are you willing to teach yourself) enough git
  to submit a pull request to the @s{(link)} repository? @p{»»}

  @p{««}I think we should remove the direct download links from the
  bitcoin.org (and wiki) homepage, too, and instead just link to the
  clients page. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1794}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-19 13:53:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1203924@s{hash}msg1203924
@section 3 {tx}

  @p{««}We're getting reports that version 0.7.0 isn't working on OSX
  10.5@p{--} are there any Mac developers with a 10.5 machine who can help
  figure out what is wrong? @p{»»}

  @p{««}The OSX builds are done on my OSX 10.6.8 machine, compiled against
  the 10.5 SDK in 32-bit mode (see @s{(link)} ) for maximum compatibility.
  I'm not sure what changed between bitcoin versions 0.6.3 and 0.7.0 that
  would break compatibility... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1795}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-19 19:25:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=51397.msg1204777@s{hash}msg1204777
@section 3 {tx}

  @p{««}You'd need 15 words to represent a bitcoin address; more if you
  include a checksum (a very good idea, transpose two words without a
  checksum and you'd get a "black hole" address). @p{»»}

  @p{««}Creating a secure payment protocol so I can tell people "send
  payment to @p{(link}gavinandresen@s{at}clearcoin.com@p{link)}" and be
  confident that I'll get the coins is very high on my priority list.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1796}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-19 21:35:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1205135@s{hash}msg1205135
@section 3 {tx}

  @s{quotedtext}

  @p{««}I'm sure I could figure it out, but I don't have a copy of osx 10.5
  to run, won't pirate it, and don't feel like spending $60 to pick up a
  copy on Ebay. I'd rather not spend the half a day it would take me to
  set up a development environment in a VM, too....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1797}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-20 19:14:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110749.msg1207474@s{hash}msg1207474
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, go ahead and implement it. Here's a thumbnail sketch of one
  way to start: @p{»»}

  @p{(li}  Create a web service that lets anybody upload their email address
  and a list of public keys.  @p{li)}

  @p{(li}  Send the user an email whenever 'tainted' coins are sent to any
  of those public keys, telling them how tainted they are and where they
  came from.  @p{li)}

  @p{««}That's it. @p{»»}

  @p{««}For extra credit, you could let users upload their wallet.dat files
  (private keys encrypted, I would hope) and auto-extract all the public
  keys in the wallet. Heck, if you stored the private-key-encrypted
  wallet.dats you might be able to charge a little for both blacklist
  detection and wallet backup. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1798}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-21 01:34:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110231.msg1208347@s{hash}msg1208347
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, these are Luke's pet branches, which I think are a bad idea
  because they divert development and testing efforts away from the latest
  release. @p{»»}

  @p{««}The first real 'stable' release will be 1.0, and we're not there
  yet.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1799}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-21 13:51:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110243.msg1209511@s{hash}msg1209511
@section 3 {tx}

  @p{««}Update, 22 Sept: Still looking for a fix for OSX 10.5 users. If you
  are running 10.5, you should not upgrade yet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1800}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-25 01:16:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=112438.msg1218085@s{hash}msg1218085
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}And I'd say the same for anybody who has offered shares on GLBSE; I
  am not a lawyer, but you should talk to a lawyer about whether or not
  you might have broken some laws you had no idea existed, and if you did,
  what you should or shouldn't do about it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1801}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-25 13:18:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=24784.msg1219427@s{hash}msg1219427
@section 3 {tx}

  @p{««}@p{(so}Yeah, where did I say that?@p{so)} @p{»»}

  @p{««}Oops, edited, I forgot about my "don't feed the trolls" rule. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1802}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-25 14:11:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101011.msg1219534@s{hash}msg1219534
@section 3 {tx}

  @s{quotedtext}

  @p{««} Wanna bet?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1803}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-26 20:49:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113006.msg1223445@s{hash}msg1223445
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, I am an angel sent from God to deliver Justice to a world
  full of @p{(bf}Sin@p{bf)}! @p{»»}

  @p{««}But I'm not behind the bitcoincard project. I did meet with them in
  Vienna, along with other bitcoin folks. See @s{(link)} for
  info/pictures. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1804}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-26 22:13:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113018.msg1223636@s{hash}msg1223636
@section 3 {tx}

  @s{quotedtext}

  @p{««}I was just about to say the same thing; if there were multiple
  people all over the world downloading and checking the binaries against
  the PGP signatures that would be a wonderful thing, and would be much
  more robust against all the various attacks that might happen (DNS
  poisoning on some subset of the Internet, compromising one mirror, etc
  etc etc). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1805}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-27 10:18:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1224721@s{hash}msg1224721
@section 3 {tx}

  @p{««}I'm pleased to announce the launch of the @p{(link}Bitcoin
  Foundation@p{link)}: @p{»»}

  @s{quotedtext}

  @p{««} The Bitcoin Foundation is modeled on the Linux Foundation. I think
  Linux is a great "role model" for Bitcoin; it is a very successful open
  source project that really embraced the notion of "open," encouraging
  the use of the core technology for a wide range of applications. @p{»»}

  @p{««}I hope that the Bitcoin Foundation will help do the same for
  Bitcoin. @p{»»}

  @p{««}Of course, "the Foundation" won't do anything at all@p{--} people
  get things done. I want the Bitcoin Foundation to be an open,
  member-driven organization, and hope that you or your organization will
  not only become a member but will help the Foundation accomplish its
  mission. @p{»»}

  @p{««}Please visit the Foundation website for details, and please keep in
  mind that nothing is set in stone; the structure of the Foundation can
  be changed by a vote of its members, and exactly what the Foundation
  does will largely depend on who is willing to step up do the work to
  make things happen. @p{»»}

  @p{««}To any of you feel like you should have been invited to be part of
  the group who defined the initial structure and purpose of the
  Foundation: I apologize. But in my experience the larger the group, the
  longer it takes to get things done, and it has been 11 months since I
  first @p{(link}posted about@p{link)} the possibility of forming a
  Foundation. @p{»»}

  @p{««} @p{hrule} In what will doubtless be an ineffective attempt to fend
  off the trolls, here are some answers to what I expect might be commonly
  asked questions: @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} Is this the infamous September Announcement? @p{»»}

  @p{««}Yes. @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} How do we know you won't just take our bitcoins
  and run? @p{»»}

  @p{««}We won't. The initial Foundation board members are all people with
  well established reputations using their real names. @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} How do we know you won't lose our bitcoins to
  hackers? @p{»»}

  @p{««}We'll be using a cold wallet, with the private key securely backed
  up, for most of the Foundation's funds; in the near future I expect
  we'll be using a multisignature cold wallet, with keys controlled by
  multiple Board members to keep the funds even more secure. @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} Is this just a front for the CIA? What is the
  hidden agenda? @p{»»}

  @p{««}No. And there is none. @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} The Foundation is a corporation, and corporations
  (especially US corporations) are evil. @p{»»}

  @p{««}OK. So don't join@p{--} go form your own non-corporate non-evil
  organization, or just ignore the Foundation and do whatever you think is
  right. @p{»»}

  @p{««}@p{(bf}Q:@p{bf)} How, exactly, is the Foundation going to spend the
  money it gets? @p{»»}

  @p{««}That depends on how many bitcoins it gets from memberships and
  donations. See @p{(link}Peter's "Letter from the Executive
  Director"@p{link)} for the current list of priorities, and see the
  @p{(link}Linux Foundation@p{link)} website for an idea of the types of
  things I hope the Bitcoin Foundation will be doing, assuming it has the
  funds. @p{»»}

  @p{««} @p{hrule} @p{brk} Finally, thanks to Peter Vessenes, Patrick
  Murck, Mark Karpeles, Charlie Shrem, Jon Matonis and Roger Ver who
  stepped up and did the work necessary to get this started.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1806}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-27 10:27:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=101011.msg1224731@s{hash}msg1224731
@section 3 {tx}

  @p{««}Y'all can stop speculating: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1807}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-27 20:01:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113496.msg1226174@s{hash}msg1226174
@section 3 {tx}

  @p{««}Is there a good open source piece of code we can use to test to
  make sure we're generating good entropy? @p{»»}

  @p{««}These bugs should be investigated and fixed (Sergio can you open
  issues on github?), but I'd like a test we could periodically run to
  make sure they stay fixed. Even better is if the code could monitor
  itself and let the user know if there's a problem with entropy
  generation. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1808}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-28 16:51:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1228692@s{hash}msg1228692
@section 3 {tx}

  @p{««}Thanks for all the positive, constructive feedback (those of you
  who gave positive, constructive feedback). I'm not going to address
  conspiracy theories, mostly because I'm not seeing most of them because
  of who I've got on my ignore list. @p{»»}

  @p{««}The points people made here about the Foundation making Bitcoin
  MORE decentralized are, from my point of view, exactly right. To take
  one example, I don't want to be the centralized decision-maker who
  figures out who should or should not be on the bitcoin-press mailing
  list that is on the bitcoin.org homepage any more. To take another: if
  there is money for the development team, I don't want to decide how to
  split it up (I've got an obvious conflict of interest). @p{»»}

  @p{««}RE: why Peter and why not anonymous members and why DC and why not
  a different process to start: @p{»»}

  @p{««}Because I'm pragmatic. I like to actually get things accomplished
  instead of endlessly talking about doing things. Everybody on the
  initial Board are people who get things done. @p{»»}

  @p{««}My biggest fear is not that the Foundation will become some
  massively powerful entity controlling Bitcoin; my biggest fear is that
  the Foundation will turn into Yet Another Ineffective Bureaucracy,
  employing a few people who do nothing but put out meaningless press
  releases. @p{»»}

  @p{««}RE: confirmation-of-payment emails: that will be done soon. @p{»»}

  @p{««}RE: bylaws: @p{»»}

  @p{««}In the spirit of openness, the Foundation bylaws are on github:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @s{quotedtext}

  @p{««} Creating forums or mailing lists where Foundation members can
  communicate is on the very short-term TODO list. @p{»»}

  @p{««}Thanks again to everybody who has already joined, it is exciting to
  see people from all over the world get involved! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1809}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-29 15:31:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=10471.msg1231092@s{hash}msg1231092
@section 3 {tx}

  @p{««}Microsoft/authenticode assumes one trusted master key (I think? Can
  a binary be signed by multiple keys?) @p{»»}

  @p{««}That is contrary to the no-central-authority idea, and it would be
  nice to avoid that. @p{»»}

  @p{««}However, given that Apple and Microsoft are both going in the
  direction of "thou shalt be a registered developer to distribute
  software for our OS" a central signing process for at least the initial
  install seems inevitable. @p{»»}

  @p{««}This is one of those "interact with existing systems that do not
  consider the possibility of radically decentralized solutions" hurdles
  that the Foundation can help jump; I expect the Foundation will soon be
  a registered Apple and Microsoft developer, and downloads will be signed
  with certificates owned by the Foundation. @p{»»}

  @p{««}The alternative is downloads only geeks can use (because only geeks
  know how to turn off cert checks) or binaries signed by me personally.
  And I don't want to be a single point of failure; having an organization
  that will hopefully outlive me is a better solution. @p{»»}

  @p{««}The best solution would be multi-signed binaries and a
  decentralized web of trust system, but we're not there yet.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1810}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-29 16:42:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110243.msg1231305@s{hash}msg1231305
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh. @p{»»}

  @p{««}That's a problem with BIP 20@p{--} it doesn't say how the
  parameters are encoded. I assumed they were encoded the same way as http
  URLs (application/x-www-form-encoded) because the bitcoin: scheme is
  very similar to the http scheme (where everything after the ? is
  x-www-form-encoded); are they not? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1811}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-29 17:01:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1231368@s{hash}msg1231368
@section 3 {tx}

  @p{««}hazek, you're really annoying me. @p{»»}

  @p{««}First, you edited my OP and broke all of the links changing .org to
  .com. @p{brk} Then you sent me a PM asking if it would be ok to move
  this thread to Service Discussion. WTF? If discussion of the Foundation
  isn't a good topic for the main Discussion forum what is? @p{»»}

  @p{««}Now you spout off about 'Gavin this, Gavin that.' @p{»»}

  @p{««}It isn't easy to piss me off, but, I'm sorry, you're really pissing
  me off. Bounties? Really? Point me to a successful security-critical
  open source project where bounties pay the rent. @p{»»}

  @p{««}I haven't tried kickstarter-like fundraising? @s{(link)} is the
  address for the Bitcoin Testing Project, which has received a grand
  total of 72 BTC, which isn't nearly enough to pay a QA grunt, let alone
  a QA lead. @p{»»}

  @p{««}You say "why change, Bitcoin has been working great for me!" @p{»»}

  @p{««}It hasn't been working great for me; I'm frustrated by the lack of
  resources and all of the distractions I have to deal with as the
  unelected, un-asked-for de-facto leader of this amazing experiment. I'm
  excited about the Foundation, because it is bringing together dedicated,
  effective people who @p{(bf}all want Bitcoin to succeed.@p{bf)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1812}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-09-30 00:17:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=96697.msg1232415@s{hash}msg1232415
@section 3 {tx}

  @s{quotedtext}

  @p{««}Right now? What if we did that and it turned out the second
  public/private algo was broken first? ECDSA is a NIST standard that has
  been very well studied and has no known vulnerabilities. There are much,
  much, much higher items on the development TODO list, like figuring out
  a nice GUI for multi-device transaction authorization. @p{»»}

  @p{««}I did write up plans for migrating to a new algorithm here: @p{»»}

    @p{(li}@s{(link)} (See the "using a quantum-resistant digital
    signature algorithm" example at the end). @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1813}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-01 21:23:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1237275@s{hash}msg1237275
@section 3 {tx}

  @p{««}If nobody steps up and volunteers to help with this, we'll have to
  drop support for OSX 10.5 in the next release. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1814}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-02 00:51:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=114664.msg1237822@s{hash}msg1237822
@section 3 {tx}

  @p{««}Jeff probably skims this sub forum for the same reasons I do@p{--}
  entertainment, to keep my mind open to new ideas, and the chance that
  there will actually be some good ideas.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1815}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-02 18:09:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=114918.msg1239719@s{hash}msg1239719
@section 3 {tx}

  @p{««}As DeathAndTaxes says, there is a weak vulnerability there for
  clients that are performing initial block download. @p{»»}

  @p{««}It is weak because try-to-fill-up-disk attacks take a long time to
  pull off, the results are boring (you managed to fill 10 gigabytes of my
  terabyte hard drive? meh), recovery is pretty easy, and the attacker has
  to wait around for potential victims to connect to them. @p{»»}

  @p{««}There are a bunch of optimizations to initial block download that
  could be done; the most obvious is fetching headers for the entire best
  blockchain starting at the best-block, then 'backfilling' block data in
  the background. That would let a new user get up and running very
  quickly, and would get rid of the vulnerability. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1816}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-02 23:36:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1240542@s{hash}msg1240542
@section 3 {tx}

  @s{quotedtext}

  @p{««} So... if the membership agrees with your "bugs" then they'll get
  fixed. Like I said, the vision is it will be a member-driven
  organization. And like I said, I find it is much more effective to start
  with something imperfect and improve it over time rather than try to get
  everything exactly right and make everybody completely happy at the
  start. @p{»»}

  @p{««}My personal opinion on the "bugs": @p{»»}

  @p{««}Name: I like the name. It can be changed if the membership decides
  on something better. @p{»»}

  @p{««}Hosting company: could easily be changed; it likely will be. I
  highly doubt Cloudflare is a government honeypot for anything besides
  catching DDoS botnet operators. @p{»»}

  @p{««}Identities/voting: Please see "Sybil Attack" for why we're
  requiring names, mailing addresses and emails. If you've got a magical
  way of identifying anonymous people please send me the source code, I
  could use it for the Bitcoin Faucet. @p{»»}

  @p{««}Privacy policy: fair point, there should be a privacy policy on the
  website. @p{»»}

  @p{««}US based: if Patrick (Foundation's lawyer) was Finnish we would
  probably be Finnish-based. That's the whole "perfect is the enemy of the
  good" thing (and I really don't want to have a month-long discussion
  about which legal jurisdiction is the least likely to declare Bitcoin
  Foundation illegal, which would be best for getting donors tax
  deductions, and whatever other arguments we could have). @p{»»}

  @s{quotedtext}

  @p{««} One of the things that I think will be fascinating to watch is how
  users and miners organize themselves (or not) to elect people to the
  Board. I'm not going to pretend that the current composition of the
  Board is perfect@p{--} I have no idea if some arrangement would be
  better. But it seems to me before making a statement like "there should
  be more of X on the Board" we should either get some experience under
  our collective belts to see how things work OR find an example of a
  similar, successful organization that works. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1817}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-02 23:40:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115024.msg1240554@s{hash}msg1240554
@section 3 {tx}

  @p{««}No, no, no: to do it right, you "accidentally" slip a hint to a
  reporter a month before you launch.... @p{»»}

  @p{««} (to the humor-impaired: @s{wink} )@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1818}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-03 19:50:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1242685@s{hash}msg1242685
@section 3 {tx}

  @s{quotedtext}

  @p{««} 50 BTC (or whatever) deposit, tied up for a minimum of a year
  (don't want somebody putting down 1,000 BTC deposits the day before a
  vote, voting 20 times, then canceling their 20 sockpuppet memberships
  and getting their deposit back immediately) is an interesting idea.
  @p{»»}

  @p{««}Call me paranoid, but I don't see many third parties who I would
  trust to not get hacked and to properly identify anonymous people. I
  don't see that third parties would have a strong incentive to do a good
  job at that. And delegating that piece of really core functionality
  feels like the wrong way to go to me. @p{»»}

  @p{««}For the record: I think it would be great to come up with an easier
  way for people to remain anonymous but still be Foundation members. I
  say "easier" because I'd guess with enough effort you could use a
  (physical) mail forwarding service and an anonymous email service to
  sign up with a fake identity. I suppose the mail forwarding service is
  like an identity-checking service. @p{»»}

  @p{««}RE: one vote per bitcoin: there seems to be some notion that
  Foundation member will be voting on things like "should a change to the
  core protocol be rolled out to support XYZ." @p{»»}

  @p{««}Umm, no. Foundation members will be voting for (and lobbying) board
  members who will decide things like "should the bylaws be changed to
  allow anonymous memberships" or "how much Foundation budget should be
  dedicated to X and how much to Y." The number of bitcoins you own has
  nothing to do with those kinds of organizational decisions. @p{»»}

  @p{««}Technical changes will happen as they have for the last couple of
  years@p{--} get rough consensus in the developer community then convince
  miners and merchants and users to upgrade. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1819}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-04 19:02:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115084.msg1245562@s{hash}msg1245562
@section 3 {tx}

  @s{quotedtext}

  @p{««} If you held a pre-signed transaction that sends the funds back to
  you with a lockTime of 1 Jan 2013 that would work. @p{»»}

  @p{««}Lets see... thinking out loud... @p{»»}

  @p{««}Start by asking the exchange for a brand-new public key to use for
  their half of the 2-of-2 transaction. Call the send-coins-into-2-of-2
  transaction "F" (for Fund). @p{»»}

  @p{««}You create and sign that transaction, but don't broadcast it yet.
  @p{»»}

  @p{««}Use it's transaction id to create a second,
  one-input-two-signature, lockTime=1/1/2013 transaction that refunds the
  coins to you. Call that "R" (for Refund). @p{»»}

  @p{««}Send R to the exchange and ask them to sign it using that brand-new
  public key they gave you. The exchange checks the lockTime and then
  returns R and the signature to you. You check the signature, and if it
  is good, broadcast F (and keep the half-signed R someplace safe). @p{»»}

  @p{««}If 1/1/2013 rolls around and you want your coins back, you sign
  your half of R and broadcast it. @p{»»}

  @p{««} @p{hrule} @p{brk} I'd have to think a little harder than I want to
  right now about whether or not signing R knowing only txid==HASH(F)
  opens up the exchange to attacks. I can't think of any, but the exchange
  providing a signature when it doesn't know the details of exactly what
  it is signing makes me nervous. @p{»»}

  @p{««}You could send the unsigned R and the signed-but-not-broadcast F to
  the exchange and trust that the exchange will not broadcast F unless
  they agree to sign R. @p{»»}

  @p{««} @p{hrule} I think holding on to pre-signed-but-not-broadcast-yet
  transactions is a technique "we" don't think about enough. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1820}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-04 21:48:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115488.msg1245952@s{hash}msg1245952
@section 3 {tx}

  @s{quotedtext}

  @p{««} Transactions do not have an input address. @p{»»}

  @p{««}They have one or more inputs, which may or may not correspond to
  one or more addresses. @p{»»}

  @p{««}If you have a CScript, then you can call: @p{»»}

  @s{code}

  @p{««} What are you trying to do? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1821}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-05 14:30:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89278.msg1247486@s{hash}msg1247486
@section 3 {tx}

  @p{««}I thought the consensus was that the mining devices just need a
  little extra software onboard to increment extranonce and recompute the
  merkle root. @p{»»}

  @p{««}I don't know nuthin about hardware/firmware design, or the
  miner@p{lt}-@s{gt}pool communication protocols, but it seems to me that
  should be pretty easy to accomplish (the device will need to know the
  full coinbase transaction, a pointer to where the extranonce is in that
  transaction, and a list of transaction hashes so it can recompute the
  merkle root). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1822}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-05 14:56:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89278.msg1247535@s{hash}msg1247535
@section 3 {tx}

  @s{quotedtext}

  @p{««} Okey doke. I thought they had some firmware that knew how to talk
  over USB (or ethernet or whatever), too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1823}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-06 16:58:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113009.msg1250536@s{hash}msg1250536
@section 3 {tx}

  @p{««}My daughter's review@p{--} "wow, these are really good nuts!" @p{»»}

  @p{««}Thanks D, we'll be ordering more! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1824}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-06 20:24:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115493.msg1251010@s{hash}msg1251010
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, that's the point: you can take any validly signed bitcoin
  transactions, tweak the signature(s) in various ways, and create
  variations that are also validly signed but have a different txid. We've
  known that for a long time. @p{»»}

  @p{««}You cannot change where the coins came from or where they go or any
  other information about the transaction that is covered by the
  signature(s). @p{»»}

  @p{««}And the current reference bitcoin implementation will simply take
  the first variation it sees and consider it valid. Sergio is saying that
  if there are any merchants doing their own double-spend detection they
  should be aware of this issue.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1825}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-07 15:02:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=116993.msg1253265@s{hash}msg1253265
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}I still hope the Bitcoin world will be boring in 4 or 5 years, but
  I expect lots more chaos and drama until at least then. This is what
  innovation looks like@p{--} lots of failures and a few spectacular
  successes. @p{»»}

  @p{««}It is still WAY too early to tell what will be successful
  long-term.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1826}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-08 23:38:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=116835.msg1257710@s{hash}msg1257710
@section 3 {tx}

  @p{««}I really and truly hope you're, right, MPOE. @p{»»}

  @p{««}But I would give 4-to-1 odds that the US justice system will
  disagree, and my advice to anybody thinking of raising funds via an
  unregulated IPO would be "don't do it unless you want to do it as a
  protest against our broken system and are willing to face the likely
  consequences." @p{»»}

  @p{««}I'll cheer you from the sidelines, but I'm either not stupid enough
  or not brave enough to go up against the SEC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1827}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-09 18:57:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115564.msg1259983@s{hash}msg1259983
@section 3 {tx}

  @p{««}I'll outsource my thoughts: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1828}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-10 00:42:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117419.msg1260874@s{hash}msg1260874
@section 3 {tx}

  @s{quotedtext}

  @p{««} Actually, there is a small incentive to forward transactions:
  @p{»»}

  @p{««}If you mine a block that contains a lot of transactions that have
  never been broadcast on the network, it will take your peers longer to
  verify that the signatures in the block are valid.* @p{»»}

  @p{««}So it takes your block longer to propagate through the network,
  which makes it slightly more likely to lose a block race. @p{»»}

  @p{««} @p{hrule} * A couple of releases ago I implemented a signature
  cache, so if a node sees a transaction broadcast it doesn't have to
  re-check it when that transaction is part of a block. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1829}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-10 15:43:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=89278.msg1262448@s{hash}msg1262448
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... so transfer 1,000 headers with different extranonces in one
  handshake. Or don't handshake every time. Or modify the firmware that
  speaks whatever mining protocol you're sending at it to do the
  increment-extranonce-and-recompute-the-merkle-root-thing itself. @p{»»}

  @p{««}All of this discussion is useless; even if you could convince us
  core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there
  is absolutely zero chance we could make that happen before the ASICS
  start shipping. @p{»»}

  @p{««}So: plan accordingly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1830}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-11 15:43:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117874.msg1264999@s{hash}msg1264999
@section 3 {tx}

  @p{««}Bitcoin version 0.7.1 release candidate 1 is now available from:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix minor release. @p{»»}

  @p{««}New features @p{»»}

  @p{««}* Added a boolean argument to the RPC 'stop' command, if true sets
  @p{»»}

    @p{(li}-detachdb to create standalone database .dat files before
    shutting down. @p{li)}

  @p{««}* -salvagewallet command-line option, which moves any existing
  wallet.dat @p{»»}

    @p{(li}to wallet.(timestamp).dat and then attempts to salvage
    public/private @p{li)}

    @p{(li}keys and master encryption keys (if the wallet is encrypted)
    into @p{li)}

    @p{(li}a new wallet.dat. This should only be used if your wallet
    becomes @p{li)}

    @p{(li}corrupted, and is not intended to replace regular wallet
    backups. @p{li)}

  @p{««}* Import $DataDir/bootstrap.dat automatically, if it exists. @p{»»}

  @p{««}Dependency changes  @p{»»}

  @p{««}* Qt 4.8.2 for Windows builds @p{»»}

  @p{««}* openssl 1.0.1c @p{»»}

  @p{««}Bug fixes @p{brk}  @p{»»}

  @p{««}* Clicking on a bitcoin: URI on Windows should now launch
  Bitcoin-Qt properly. @p{»»}

  @p{««}* When running -testnet, use RPC port 18332 by default. @p{»»}

  @p{««}* Better detection and handling of corrupt wallet.dat and
  blkindex.dat files. @p{»»}

    @p{(li}Previous versions would crash with a DB_RUNRECOVERY exception,
    this @p{li)}

    @p{(li}version detects most problems and tells you how to recover if
    it @p{li)}

    @p{(li}cannot recover itself. @p{li)}

  @p{««}* Fixed an uninitialized variable bug that could cause transactions
  to @p{»»}

    @p{(li}be reported out of order. @p{li)}

  @p{««}* Fixed a bug that could cause occasional crashes on exit. @p{»»}

  @p{««}* Warn the user that they need to create fresh wallet backups after
  they @p{»»}

    @p{(li}encrypt their wallet. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1831}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-11 17:18:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117663.msg1265239@s{hash}msg1265239
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh? There were none. The blockchain bootstraps itself from the
  genesis block and peers on the network. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1832}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-11 21:16:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117920.msg1265877@s{hash}msg1265877
@section 3 {tx}

  @s{quotedtext}

  @p{««}There's no such thing as 'official.' @p{»»}

  @p{««}I think the best term is "reference client." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1833}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-12 19:57:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117874.msg1268084@s{hash}msg1268084
@section 3 {tx}

  @s{quotedtext}

  @p{««} This will be a WONTFIX, unless somebody steps up to continue
  supporting OSX 10.5. @p{»»}

  @p{««}I'll put a big note in the release notes that we're dropping OSX
  10.5 support. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1834}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-13 01:05:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117874.msg1268659@s{hash}msg1268659
@section 3 {tx}

  @s{quotedtext}

  @p{««}I slapped one up you can try: @s{(link)} @p{»»}

  @p{««}I think typing bitcoin:1.....?label=... etc into the browser
  address bar should work for testing, too. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1835}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-13 13:08:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=118198.msg1269335@s{hash}msg1269335
@section 3 {tx}

  @s{quotedtext}

  @p{««}Not yet. There is a pull request implementing bloom filters that
  should make that easy to implement. @p{»»}

  @s{quotedtext}

  @p{««}No. The reference implementation doesn't keep a master map of all
  addresses to unspent transaction outputs, and adding such an index for
  the small number of services that need to look up arbitrary addresses
  doesn't make sense. @p{»»}

  @p{««}I'd suggest you -blocknotify and the getblock() RPC call to
  maintain your own index of address @p{--}@s{gt} unspent txout. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1836}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-14 02:13:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=118340.msg1270727@s{hash}msg1270727
@section 3 {tx}

  @s{quotedtext}

  @p{««}If I recall correctly, mybitcoin.com users got 49% of their coins
  back (I was one of the stupid people who trusted some bitcoins to them,
  by the way). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1837}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-14 02:37:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=118198.msg1270759@s{hash}msg1270759
@section 3 {tx}

  @s{quotedtext}

  @p{««}Right, and we don't accept "change the world" pull requests because
  the risks of introducing a catastrophic bug outweigh the benefits, and
  rewriting everything invalidates all of the careful code review that's
  been done over the past few years. @p{»»}

  @p{««}However, we ARE moving towards better architecture as different
  parts of the code get worked on to support new features or improve
  scalability or fix bugs. For an example of inversion-of-control done
  right, look for use of boost signals and slots; for example: @p{»»}

  @p{««}Code: boost::signals2::signal@p{lt}void (CWallet *wallet, const
  uint256 &amp;hashTx, ChangeType status)@s{gt} NotifyTransactionChanged;

# ----------------------------------------------------------------------
@section 2 {ms1838}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-14 19:00:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113018.msg1272031@s{hash}msg1272031
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nice! You should submit a pull request to put a version of this in
  the contrib/ directory; my only suggestion would be to make it take a
  version string as an argument (and maybe automatically look in the test/
  subdirectory if it contains 'rc'). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1839}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-14 19:55:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1272155@s{hash}msg1272155
@section 3 {tx}

  @p{««}RE: do I have gazillions of bitcoins: @p{»»}

  @p{««}I've said before that I have "thousands of bitcoins, not tens or
  hundreds of thousands of bitcoins." I have mined a grand total of 250
  bitcoins@p{--} electricity here is not particularly cheap, and I'm a
  software kind of guy, not a hardware hacker. So it always made more
  sense for me to buy bitcoins rather than mining them. @p{»»}

  @p{««}I would definitely be wealthier right now if I had been working as
  the CTO for a company for the last two years and had never heard of
  Bitcoin. @p{»»}

  @p{««}RE: what work will I do: @p{»»}

  @p{««}I will continue doing what I've been doing@p{--} trying to focus on
  work that benefits all of Bitcoin and not one particular company. That
  is the kind of work that falls through the cracks@p{--} why would one
  company pay for cross-implementation compatibility tests? Sure
  cross-implementation compatibility is really important for the stability
  of the Bitcoin network, but as long as the implementation THEY'RE using
  works properly then why would they spend extra to make life easier for
  other implementations? @p{»»}

  @p{««}Or a company might fund the development of anti-denial-of-service
  techniques, but once they do, why would they want to share that with
  their competitors? Being more denial-of-service-resistant might give
  them a competitive advantage... @p{»»}

  @p{««}TruCoin paid me a salary for a couple of months last year to do
  core development work (and paid Alex Waters to start doing Q/A for core
  development), but TruCoin ran into funding problems of their own and
  stopped paying us to concentrate on their own projects. @p{»»}

  @p{««}Creating a Foundation is a proven, well-established way for
  projects to solve the free-rider problem of funding core development
  that benefits everybody. Over time, I hope to be working less on the
  reference implementation and more on "Chief Scientist" stuff, like
  organizing working groups to write best practices documents or work out
  agreements on changes that might be necessary to the core protocol to
  support more transactions, better privacy, advances in quantum
  computing, hiring or recruiting experts to do security reviews of
  proposed new stuff, etc. @p{»»}

  @p{««}RE: voting: @p{»»}

  @p{««}Great ideas! I think I'll be pushing to start with a good
  old-fashioned "send you a letter with a PIN number to your mailing
  address" as the first step to preventing voter fraud. We'll have to have
  a much more extensive discussion of voting procedures before it is time
  to vote. I'll probably push to follow the lead of other successful
  organizations, and to do the Simplest Possible Thing That Will
  Work@p{--} which might be hiring a disinterested high-reputation company
  who specializes in running elections for organizations. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1840}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-15 18:30:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115084.msg1274086@s{hash}msg1274086
@section 3 {tx}

  @s{quotedtext}

  @p{««} You don't need the whole network to support transaction
  replacement to do that; just write some code that holds a time-locked
  transaction, has a way of replacing it with another time-locked
  transaction, and have it automatically broadcast the transaction onto
  the network if not replaced before the time-lock expires. @p{»»}

  @p{««}It would be more convenient to have the whole network support
  transaction replacement, but I don't think it is reasonable for the
  whole network to remember everybody's dead-man-switch transactions. And
  even if they did, you'd run the risk that a miner eager to get an extra
  transaction fee would ignore a newer version of the transaction and mine
  the old transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1841}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-16 11:37:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=117457.msg1275699@s{hash}msg1275699
@section 3 {tx}

  @s{quotedtext}

  @p{««}It is MIT licensed, anybody can mirror it anywhere they like. You
  don't need anybody's permission, just do it! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1842}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-19 13:23:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=119277.msg1283232@s{hash}msg1283232
@section 3 {tx}

  @p{««}Bitcoin version 0.7.1 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix minor release. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Project source code is hosted at github; you can get @p{brk}
  source-only tarballs/zipballs directly from there: @p{»»}

    @p{(li}@s{(link)} @s{hash} .tar.gz @p{li)}

    @p{(li}@s{(link)} @s{hash} .zip @p{li)}

  @p{««}Ubuntu Linux users can use the "Personal Package Archive" (PPA)
  @p{brk} maintained by Matt Corallo to automatically keep @p{brk}
  up-to-date. Just type: @p{»»}

    @p{(li}sudo apt-add-repository ppa:bitcoin/bitcoin @p{li)}

    @p{(li}sudo apt-get update @p{li)} in your terminal, then install the
  bitcoin-qt package: @p{»»}

    @p{(li}sudo apt-get install bitcoin-qt @p{li)}

  @p{««}KNOWN ISSUES  @p{»»}

  @p{««}Mac OSX 10.5 is no longer supported. @p{»»}

  @p{««}How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you were running on Linux with a version that might have been
  compiled @p{brk} with a different version of Berkeley DB (for example,
  if you were using an @p{brk} Ubuntu PPA version), then run the old
  version again with the -detachdb @p{brk} argument and shut it down; if
  you do not, then the new version will not @p{brk} be able to read the
  database files and will exit with an error. @p{»»}

  @p{««}Explanation of -detachdb (and the new "stop true" RPC command):
  @p{brk} The Berkeley DB database library stores data in both ".dat" and
  @p{brk} "log" files, so the database is always in a consistent state,
  @p{brk} even in case of power failure or other sudden shutdown. The
  @p{brk} format of the ".dat" files is portable between different @p{brk}
  versions of Berkeley DB, but the "log" files are not@p{--} even minor
  @p{brk} version differences may have incompatible "log" files. The
  @p{brk} -detachdb option moves any pending changes from the "log" files
  @p{brk} to the "blkindex.dat" file for maximum compatibility, but makes
  @p{brk} shutdown much slower. Note that the "wallet.dat" file is always
  @p{brk} detached, and versions prior to 0.6.0 detached all databases
  @p{brk} at shutdown. @p{»»}

  @p{««}New features @p{brk} 
  @p{»»}

  @p{««}* Added a boolean argument to the RPC 'stop' command, if true sets
  @p{»»}

    @p{(li}-detachdb to create standalone database .dat files before
    shutting down. @p{li)}

  @p{««}* -salvagewallet command-line option, which moves any existing
  wallet.dat @p{»»}

    @p{(li}to wallet.(timestamp).dat and then attempts to salvage
    public/private @p{li)}

    @p{(li}keys and master encryption keys (if the wallet is encrypted)
    into @p{li)}

    @p{(li}a new wallet.dat. This should only be used if your wallet
    becomes @p{li)}

    @p{(li}corrupted, and is not intended to replace regular wallet
    backups. @p{li)}

  @p{««}* Import $DataDir/bootstrap.dat automatically, if it exists. @p{»»}

  @p{««}Dependency changes  @p{»»}

  @p{««}* Qt 4.8.2 for Windows builds @p{»»}

  @p{««}* openssl 1.0.1c @p{»»}

  @p{««}Bug fixes @p{brk} @p{»»}

  @p{««}* Clicking on a bitcoin: URI on Windows should now launch
  Bitcoin-Qt properly. @p{»»}

  @p{««}* When running -testnet, use RPC port 18332 by default. @p{»»}

  @p{««}* Better detection and handling of corrupt wallet.dat and
  blkindex.dat files. @p{»»}

    @p{(li}Previous versions would crash with a DB_RUNRECOVERY exception,
    this @p{li)}

    @p{(li}version detects most problems and tells you how to recover if
    it @p{li)}

    @p{(li}cannot recover itself. @p{li)}

  @p{««}* Fixed an uninitialized variable bug that could cause transactions
  to @p{»»}

    @p{(li}be reported out of order. @p{li)}

  @p{««}* Fixed a bug that could cause occasional crashes on exit. @p{»»}

  @p{««}* Warn the user that they need to create fresh wallet backups after
  they @p{»»}

    @p{(li}encrypt their wallet. @p{li)}

  @p{««} Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Gavin Andresen @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Mark
  Friedenbach @p{brk} Matt Corallo @p{brk} Philip Kaufmann @p{brk} Pieter
  Wuille @p{brk} Rune K. Svendsen @p{brk} Virgil Dupras @p{brk} Wladimir
  J. van der Laan @p{brk} fanquake @p{brk} kjj2 @p{brk} xanatos @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1843}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-20 12:56:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=118994.msg1285581@s{hash}msg1285581
@section 3 {tx}

  @p{««}It should be pretty easy to use the raw transactions API to
  implement a "send all". @p{»»}

  @p{««}You would do: @p{»»}

    @p{(li}listunspent @p{--}@s{gt} list of inputs @p{li)}

    @p{(li}Then estimate a reasonable fee (this is the hardest bit, but
    listunspent tells you amount and @s{hash}confirmations and you can estimate
    tx size based on number of inputs) @p{li)}

    @p{(li}createrawtransaction/signrawtransaction/sendrawtransaction
    @p{li)}

  @p{««}Somebody should write a little python tool we can ship in contrib/

# ----------------------------------------------------------------------
@section 2 {ms1844}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-24 22:13:39 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=120429.msg1295798@s{hash}msg1295798
@section 3 {tx}

  @p{««}If you receive income in any form, and your
  income-translated-into-dollars is above whatever the "must file" amount
  currently is, then yes, you must report it on your income taxes at the
  end of the year. @p{»»}

  @p{««}Doesn't matter if your income is in the form of dollars or euros or
  bitcoins or diamonds. @p{»»}

  @p{««}And I'm pretty sure Fincen would say that if you're receiving more
  than $10,000 worth of bitcoins from somebody then they want to know
  about it, just like they want to know if you're getting more than
  $10,000 worth of diamonds from somebody. See the fincen.gov for the
  mind-numbing details. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1845}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-27 19:14:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=120473.msg1301958@s{hash}msg1301958
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think that is a good thought experiment: If you replaced all
  uses of SHA256 in Bitcoin with MD5, what attacks would be possible?
  (please check my work, I am not an expert on hash collisions) @p{»»}

  @p{««}Well, to @p{(link}generate a collision@p{link)}: @p{»»}

  @s{quotedtext}

  @p{««} Block hashing would be safe, for now; the block header that is
  hashed is only 80 bytes long, much less than the 128 bytes of wiggle
  room needed to find a collision. @p{»»}

  @p{««}I believe an attacker could easily produce two different
  non-standard transactions that hashed to the same txid. That would be a
  disaster, they could split the blockchain and/or double-spend by
  broadcasting one version of the transaction to half the network and the
  other to the other half of the network. @p{»»}

  @p{««}To split the chain the attacker would mine a block containing the
  'poison' transaction hash, and then broadcast two versions of the same
  block, containing the two different-but-same-hash transactions. Half the
  network would think that block contains 't1', and half 't2'. Everything
  would be just fine until the attacker spent the outputs of t1 and/or
  t2... then Bad Things would happen. @p{»»}

  @p{««}Double-hashing doesn't help at all: If HASH(t1) == HASH(t2) then
  HASH(HASH(t1)) == HASH(HASH(t2)) @p{»»}

  @p{««} @p{hrule} I do agree with everybody who points out that SHA256
  isn't close to being broken. If it does ever start to get close, then
  I'm sure we could figure out a backwards-compatible fixes and phase them
  in (something like "a block's coinbase transaction must include a
  SHA3-based transaction merkle root", create a new version of OP_CHECKSIG
  that used SHA3, roll out a new alert system that used SHA3, etc). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1846}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-27 19:41:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=120836.msg1302002@s{hash}msg1302002
@section 3 {tx}

  @s{quotedtext}

  @p{««}Okey dokey. @p{»»}

  @p{««}Reality is that the protocol @p{(bf}IS@p{bf)} defined by Satoshi's
  implementation. @p{»»}

  @p{««}This isn't like HTML where the worst thing that happens if two
  implementations disagree about the spec you get different looking web
  pages. Our worst case is much worse (if two popular implementations
  disagree then we potentially wind up with a blockchain split, and,
  essentially, two different currencies). @p{»»}

  @p{««}We need help creating tests to make sure different implementations
  agree on the rules; as you re-implement the protocol please set aside
  some time to think about that and help! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1847}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-27 20:53:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105505.msg1302139@s{hash}msg1302139
@section 3 {tx}

  @p{««}Hmmm.... works for me. See: @s{(link)} for exactly what I did to
  create and then spend a 2-of-3 on the main network, with keys that are
  not in my wallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1848}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-28 00:56:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=105505.msg1302500@s{hash}msg1302500
@section 3 {tx}

  @p{««}Thanks for helping test! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1849}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-10-30 15:46:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=118780.msg1307185@s{hash}msg1307185
@section 3 {tx}

  @p{««}The first thing your committee should do is come up with a better
  name. @p{»»}

  @p{««}There is a reason the phrase "designed by committee" is one of the
  worst things you can say about a project. @p{»»}

  @p{««}And if your committee can't agree on a better name... then you're
  doomed before you start. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1850}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-01 15:11:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=120960.msg1310928@s{hash}msg1310928
@section 3 {tx}

  @p{««}See @s{(link)} : @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1851}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-01 20:43:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1311660@s{hash}msg1311660
@section 3 {tx}

  @p{««}dansmith: @p{»»}

  @p{««}Here's a -g build: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}If I recall correctly, one of the libraries it links with is
  incompatible with 10.5. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1852}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-02 18:10:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122079.msg1313405@s{hash}msg1313405
@section 3 {tx}

  @p{««}The relevant settings and their default values for recent versions
  of bitcoind are: @p{»»}

  @p{««} Code: Maximum size, in bytes, of blocks you create: @p{brk}
  blockmaxsize=250000 @p{»»}

  @p{««}How many bytes of the block should be dedicated to high-priority
  transactions, @p{brk} included regardless of the fees they pay @p{brk}
  blockprioritysize=27000 @p{»»}

  @p{««}Minimum block size you want to create; block will be filled with
  free transactions @p{brk} until there are no more or the block reaches
  this size: @p{brk} blockminsize=0 @p{»»}

  @p{««}Fee-per-kilobyte amount (in BTC) considered the same as "free"
  @p{brk} Be careful setting this: if you set it to zero then @p{brk} a
  transaction spammer can cheaply fill blocks using @p{brk} 1-satoshi-fee
  transactions. It should be set above the real @p{brk} cost to you of
  processing a transaction. @p{brk} mintxfee=0.0005 @p{»»}

  @p{««} So if you set blockprioritysize=0, you will only accept fee-paying
  transactions. @p{»»}

  @p{««}If you only want to accept 500 or so transactions, set the
  blocksize to 500 * average transaction size (400 bytes or so) = 200000
  @p{»»}

  @p{««}The rules for filling up the block are: @p{»»}

  @p{««}First, take the highest priority transactions (regardless of fee)
  and fill up the block to blockprioritysize. (if blockprioritysize is
  zero, then this step does not apply) @p{»»}

  @p{««}Then, take the highest fee-per-kilobyte transactions and continue
  filling the block until either you run out of transactions with a
  fee-per-kilobyte greater than mintxfee or the block would be larger than
  blockmaxsize. @p{»»}

  @p{««}Finally: the rules are likely to change again fairly soon so that
  groups of related transactions are considered together ("child pays for
  parent", so customers can send zero-fee transactions to merchants, who
  can create a child transaction with a fee when they need the transaction
  to be confirmed). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1853}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-02 18:16:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122013.msg1313414@s{hash}msg1313414
@section 3 {tx}

  @p{««}Does it run on the testnet blockchain? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1854}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-02 20:28:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=113400.msg1313684@s{hash}msg1313684
@section 3 {tx}

  @s{quotedtext}

  @p{««}Because Foundation members posting on the forum may not want the
  entire world to know that they are Foundation members with a quick
  Google search@p{--} there is a privacy issue. @p{»»}

  @p{««}Somebody could sign up as a member and then try to screen-scrape
  and republish everything somewhere, so members should assume that
  whatever they say will eventually be public. And the membership might
  still decide that read-only for non-members is the right thing to
  do@p{--} I agree that it could be a good way to attract new members, if
  the quality of conversation is high. @p{»»}

  @p{««}In related news: Foundation board members will be blogging
  regularly at @s{(link)} @p{brk} (RSS feed: @s{(link)} )@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1855}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-04 23:48:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1316983@s{hash}msg1316983
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, I believe I did. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1856}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-06 02:49:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1319150@s{hash}msg1319150
@section 3 {tx}

  @p{««}Ummm.... @p{brk} .... yeah. @p{»»}

  @p{««}Sorry, but tweaking and recompiling my macports boost to support
  OSX 10.5, which is not longer being supported by Apple (or Chrome or
  several other popular projects) just isn't very high on my TODO list.
  @p{»»}

  @p{««}Figuring out why it used to work is even lower on my list. @p{»»}

  @p{««}Perhaps you can convince people that you're trustworthy, and
  release a 10.5-compiled binary yourself. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1857}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-06 16:11:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122611.msg1320046@s{hash}msg1320046
@section 3 {tx}

  @s{quotedtext}

  @p{««} Recent versions support JSON-2.0 "batch" queries, so you can
  combine multiple RPC calls into one batch and get a list of responses.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1858}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-06 21:29:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122681.msg1320700@s{hash}msg1320700
@section 3 {tx}

  @p{««}See @s{(link)} @p{»»}

  @p{««}There are three active alerts right now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1859}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-06 21:34:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122274.msg1320714@s{hash}msg1320714
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1 : most organizations won't appreciate getting random bitcoin
  donations, it is a headache for them to figure out how to handle them
  properly (and they will get pretty grumpy if they spend a couple hundred
  dollars worth of staff time to deal with less than that in bitcoin
  donations).  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1860}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-08 02:15:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122904.msg1323369@s{hash}msg1323369
@section 3 {tx}

  @p{««}I wonder if that is the smallest sha256 hash ever found for any
  purpose...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1861}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-14 00:08:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=77870.msg1333746@s{hash}msg1333746
@section 3 {tx}

  @s{quotedtext}

  @p{««}Agreed, thanks Erik! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1862}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-14 00:32:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=124113.msg1333775@s{hash}msg1333775
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1863}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-14 14:49:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=124202.msg1334634@s{hash}msg1334634
@section 3 {tx}

  @p{««}Is that 0.00095 from a single input, or is it 95 .00001 inputs?
  @p{»»}

  @p{««}0.00095 BTC is worth about one US cent. Are you sure it is worth
  your time to try to get that penny back? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1864}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-15 19:14:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=123488.msg1337155@s{hash}msg1337155
@section 3 {tx}

  @s{quotedtext}

  @p{««}So... please don't take this the wrong way, but what's your prior
  experience creating and shipping high-quality software? @p{»»}

  @p{««}I ask because re-implementing Bitcoin as a first
  "software-people-other-than-myself-are-going-to-use" project is a really
  bad idea, I don't see any list of previous work at the RocketHub page,
  and the 9,000 lines of code you've already written doesn't look like the
  work of somebody who has professional software development experience
  (e.g. no makefile/build system ...). @p{»»}

  @p{««}Maybe you're a prodigy and will get it right the first time, but
  you're already at 'cbitcoin 2.0' because you weren't happy with how
  'cbitcoin 1.0' was turning out. See the solidcoin/microcash saga for an
  example of how over-promising "1.0/2.0/3.0" releases destroys
  confidence. @p{»»}

  @p{««}And maybe you CAN point to some other successful software you wrote
  and shipped when you were 17, in which case I'll shut up and leave you
  alone. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1865}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-15 19:35:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=122632.msg1337214@s{hash}msg1337214
@section 3 {tx}

  @s{quotedtext}

  @p{««}See: @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1866}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-16 16:51:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=40264.msg1339172@s{hash}msg1339172
@section 3 {tx}

  @s{quotedtext}

  @p{««} You should only trust tags fetched via https, otherwise a
  man-in-the-middle could hijack the .json file and replace the address
  and signature. @p{»»}

  @p{««}(and I think you'd want "tags" to be an Array of Objects...) @p{»»}

  @p{««}RE: adding data to the blockchain: Did you see Stefan Thomas'
  @p{(link}nifty idea@p{link)} for using ECC math to tie a hash to a
  transaction without any blockchain bloat? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1867}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-21 02:54:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=126865.msg1348712@s{hash}msg1348712
@section 3 {tx}

  @p{««}listunspent output is designed to be read by machines, not people,
  and its output is designed to go directly into createrawtransaction.
  @p{»»}

  @p{««}If you need all the human-friendly details of a transaction, use
  getrawtransaction @p{lt}txid@s{gt} 1 @p{»»}

  @p{««}I'm against adding "address" to the listunspent output, because
  most of the time it will be unused and sometimes it would just not
  appear at all (because not all scriptPubKeys are bitcoin
  addresses).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1868}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-29 13:35:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128119.msg1366520@s{hash}msg1366520
@section 3 {tx}

  @s{quotedtext}

  @p{««}You can use plain multisig if you like, they WERE added to
  IsStandard.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1869}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-29 22:53:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128442.msg1367664@s{hash}msg1367664
@section 3 {tx}

  @p{««}For those of you not subscribed to
  @p{(link}bitcoin-development@s{at}lists.sourceforge.net@p{link)} : @p{»»}

  @p{««}We've been having a productive discussion of a proposal for a
  simple payment protocol to get a much better user experience than is
  given by bitcoin addresses: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is the next big "lets all agree to do things the same way"
  thing I think we should tackle. Latest pseudo-spec is: @s{(link)} @p{»»}

  @p{««}I'd prefer to keep the discussion on the mailing list (I think this
  forum is a great place for brainstorming, but I think the mailing list
  is a little better for getting consensus on all the nitty-gritty details
  of a proposal). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1870}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-29 23:01:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128413.msg1367689@s{hash}msg1367689
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't think we'll @p{(bf}know@p{bf)} if it can work until it is
  tried; it does seem to me that the incentives point the wrong way (if my
  doctor tells me I have six months to live maybe I decide I deserve to
  run up my Ripple credit to the max....) but maybe I'm just cynical
  (maybe there will be an equal or greater number of people who decide to
  give away all their money through Ripple instead of leave it to their
  deadbeat children). @p{»»}

  @p{««}Good luck to Joel and Jed and the rest of the Ripple team! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1871}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-30 14:28:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128475.msg1369018@s{hash}msg1369018
@section 3 {tx}

  @p{««}I should talk with Valve? @p{»»}

  @p{««}I'm not an expert in video game economics, and I haven't yet seen a
  strong argument for why a game company would give up control of their
  own in-game currencies for a currency that they do not (and cannot)
  control. @p{»»}

  @p{««}If you've got a strong argument for why they should, then
  @p{(bf}YOU@p{bf)} should talk with Valve*. They're rational and
  profit-driven, so if it is in their best interest they should be willing
  to do it. @p{»»}

  @p{hrule} 

  @p{««} *Cue a flood of armchair-game-economists posting their
  half-baked thoughts here... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1872}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-11-30 16:48:52 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128548.msg1369366@s{hash}msg1369366
@section 3 {tx}

  @p{««}Yes, if they have an infinite amount of money to pay in transaction
  fees. @p{»»}

  @p{««}I'm not sure why governments would want to give all of their money
  to miners, though. And buying up bitcoins to pay all those fees would
  just push up the price, so it would probably be counter-productive as a
  way of trying to ddos the network.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1873}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-01 01:00:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128442.msg1370510@s{hash}msg1370510
@section 3 {tx}

  @s{quotedtext}

  @p{««} You will be able to generate and send unsigned invoices that has
  no identity attached. @p{»»}

  @p{««}But they are much less secure than signed invoices, because a "man
  in the middle" attacker could rewrite the Invoice so the bitcoins go to
  him. @p{»»}

  @p{««}Or if you have a dispute with the merchant and all you have is an
  unsigned Invoice, the merchant can claim that "your machine must have
  been hacked, you sent the bitcoins to an address that isn't mine!" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1874}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-02 16:03:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128442.msg1373124@s{hash}msg1373124
@section 3 {tx}

  @s{quotedtext}

  @p{««} I would urge you to return a receipt with a memo that says: @p{»»}

  @p{««}"your order will be shipped as soon as your payment has three
  confirmations." @p{»»}

  @p{««}Explicitly telling your customers what they can expect to happen
  next is a great feature of the proposal, I think. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1875}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-04 19:48:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=110605.msg1377965@s{hash}msg1377965
@section 3 {tx}

  @p{««}Can you please let me know if this works on OSX 10.5: @p{»»}

    @p{(li} @s{(link)} @p{li)}

  @p{««}I set up a new build environment on an old, 32-bit OSX 10.6 laptop,
  and I think I fixed the 10.5 compatibility issue. @p{»»}

  @p{««}(some MacPorts maintainers don't seem to be terribly good at making
  sure their ports honor BOTH the -arch AND the -isysroot settings...)
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1876}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-04 22:24:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128823.msg1378372@s{hash}msg1378372
@section 3 {tx}

  @p{««}No, you probably won't get a response there, either. @p{»»}

  @p{««}"All BIPs should" ... is too rigid, in my humble opinion. @p{»»}

  @p{««}If the person championing the BIP thinks that a link to a
  discussion thread helps clarify or convince, then they should include a
  link. But I don't think a hard-and-fast rule is the right thing to do,
  we'll just waste time arguing over WHICH discussion thread or threads
  should be linked... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1877}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-05 17:51:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=129288.msg1380107@s{hash}msg1380107
@section 3 {tx}

  @p{««}The main reason for this release is to fix a nasty bug in the RPC
  'move' command that was introduced in 0.7.0. @p{»»}

  @p{««} Bitcoin version 0.7.2rc2 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix minor release. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}How to Upgrade  @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you were running on Linux with a version that might have been
  compiled @p{brk} with a different version of Berkeley DB (for example,
  if you were using an @p{brk} Ubuntu PPA version), then run the old
  version again with the -detachdb @p{brk} argument and shut it down; if
  you do not, then the new version will not @p{brk} be able to read the
  database files and will exit with an error. @p{»»}

  @p{««}Explanation of -detachdb (and the new "stop true" RPC command):
  @p{brk} The Berkeley DB database library stores data in both ".dat" and
  @p{brk} "log" files, so the database is always in a consistent state,
  @p{brk} even in case of power failure or other sudden shutdown. The
  @p{brk} format of the ".dat" files is portable between different @p{brk}
  versions of Berkeley DB, but the "log" files are not@p{--} even minor
  @p{brk} version differences may have incompatible "log" files. The
  @p{brk} -detachdb option moves any pending changes from the "log" files
  @p{brk} to the "blkindex.dat" file for maximum compatibility, but makes
  @p{brk} shutdown much slower. Note that the "wallet.dat" file is always
  @p{brk} detached, and versions prior to 0.6.0 detached all databases
  @p{brk} at shutdown. @p{»»}

  @p{««}Bug fixes @p{brk} @p{»»}

  @p{««}* Prevent RPC 'move' from deadlocking. This was caused by trying to
  lock the @p{»»}

    @p{(li}database twice. @p{li)}

  @p{««}* Fix use-after-free problems in initialization and shutdown, the
  latter of @p{»»}

    @p{(li}which caused Bitcoin-Qt to crash on Windows when exiting.
    @p{li)}

  @p{««}* Correct library linking so building on Windows natively works.
  @p{»»}

  @p{««}* Avoid a race condition and out-of-bounds read in block
  creation/mining code. @p{»»}

  @p{««}* Improve platform compatibility quirks, including fix for 100% CPU
  utilization @p{»»}

    @p{(li}on FreeBSD 9. @p{li)}

  @p{««}* A few minor corrections to error handling, and updated
  translations. @p{»»}

  @p{««}* OSX 10.5 supported again @p{»»}

  @p{««} Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Alex @p{brk} dansmith @p{brk} Gavin Andresen @p{brk} Gregory
  Maxwell @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Philip Kaufmann
  @p{brk} Pieter Wuille @p{brk} Wladimir J. van der Laan @p{brk} grimd34th
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1878}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-06 01:01:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=73648.msg1381074@s{hash}msg1381074
@section 3 {tx}

  @p{««}RE: building the .app bundle: @p{»»}

  @p{««}@s{(link)} @p{brk} ... is python code with lots of useful stuff for
  building a nice .app (including making a pretty-looking .dmg). @p{brk}
  Lots of Qt-specific stuff, too, but it might be a good starting point.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1879}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-09 16:53:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=92658.msg1388479@s{hash}msg1388479
@section 3 {tx}

  @p{««}12r6DPnX5TNK4PhnTiShmuK6o4jE8Yh28C @p{»»}

  @p{««}Received, rounded up to 3.11 BTC (because eleven is my favorite
  number) and sent: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1880}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-09 17:06:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=129943.msg1388510@s{hash}msg1388510
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think Jon has been pretty consistently on the "less regulation
  is better regulation" side of the debate. Given that the big criticism
  of the Bitcoin Foundation (and Mt. Gox) around here was that it is on
  the "more regulation" side of the fence, I find your comment kind of
  amusing. @p{»»}

  @p{««}As for it being "a big pile of fail" : I think reasonable people
  can disagree here. I have no idea whether trying to work inside the
  existing system or working around the existing system is a better
  approach. You have your opinion, Jon has his, I think we'll be arguing
  about it for years to come; happily, there doesn't have to be One True
  Answer. I just hope we don't spend all our time sniping at each other
  over the best One True Way to reach the goals that we all share. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1881}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-13 03:28:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130456.msg1396585@s{hash}msg1396585
@section 3 {tx}

  @p{««}Wow, great paper! @p{»»}

  @p{««}I like the idea of the "bill" (aka contract aka "PaymentRequest")
  determining the payment address, and the merchant's private
  bitcoin-signing key or keys being stored off their web server. @p{»»}

  @p{««}I'll append some half-baked thoughts below on melding the current
  PaymentRequest proposal with your ideas. @p{»»}

  @p{««}Using a Merkle tree to reveal (or not) parts of the bill is a nifty
  idea, but I think that is orthogonal to the payment protocol, and could
  be a generic way of encoding any document. I tend to agree with Mike, it
  feels like a complex solution to something that really isn't a problem
  right now (maybe if we ever have CyberCourts to adjudicate disputes
  between anonymous customers and merchants it will be useful). @p{»»}

  @p{««}PS: I was amused by: @p{»»}

  @p{««}Code: An implementation with bitcoin would require little effort.
  Writing the code should be fairly straightforward; getting everybody to
  agree to the dozens of details we'll need to work out will be more than
  a little effort. @p{»»}

  @p{««} @p{hrule} @p{brk} So in the PaymentRequest protocol, a
  SignedPaymentRequest contains a PaymentRequest that you know came from
  the merchant's web server (leveraging the SSL/TLS/PKI/X.509 certificate
  system that we all agree is the worst PKI system there is, except for
  all the other that have been tried): @p{»»}

  @p{««} @s{code}

    @p{(li}pki_type = "x509" @p{li)}

    @p{(li}pki_data = ... certificate chain... @p{li)}

    @p{(li}signature = ... @p{li)}

    @p{(li}serialized_payment_request = ...PaymentRequest containing
    Outputs where payment will go... @p{li)}

    @p{(li}etc @p{li)}

  @p{««} As your paper points out, if an attacker compromises the webserver
  then they can redirect bitcoins to their wallet. @p{»»}

  @p{««}It would be nice if that was impossible, and your paper shows how
  to do that. In the PaymentRequest scheme, one way of doing that might
  be: @p{»»}

  @p{««} @s{code}

    @p{(li}pki_type = "x509_homomorphic" @p{li)}

    @p{(li}pki_data = ... certificate chain... @p{li)}

    @p{(li}signature = ... @p{li)}

    @p{(li}serialized_payment_request = ...PaymentRequest containing no
    Outputs... @p{li)}

    @p{(li}etc @p{li)}

  @p{««} The merchant's certificate in the certificate chain would have to
  contain their base bitcoin public key (or as you point out in the paper,
  generalized to a "base script"). I think that could be done using an
  X.509 extended attribute (anybody know if certificate authorities will
  sign certificates that contain non-standard extensions?). @p{»»}

  @p{««}The customer would hash the serialized_payment_request, combine it
  with the base key/script, and pay to that address/script. @p{»»}

  @p{««} @p{hrule} The TODO list for implementing the simpler "x509"
  payment requests is fairly long (help appreciated by the way, see
  @s{(link)} ); implementing "x509_homomorphic" would make it even longer.
  I think we need to implement the simpler protocol first, because I think
  small merchants will want to re-use their existing web server
  certificates instead of paying for a new "x509_homomorphic" certificate
  that contains their "bitcoin identity" public key. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1882}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 01:51:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130544.msg1398769@s{hash}msg1398769
@section 3 {tx}

  @p{««}Disclaimer: I'm bad at predicting the future. @p{»»}

  @p{««}Will governments create a crypto-currency to try to compete? @p{»»}

  @p{««}The "network effect" is really important for money. Any form of
  money gains value as more people use it. @p{»»}

  @p{««}It is possible that Bitcoin (or any future crypto-currency) will
  never be able to gain enough use to overcome big, existing currencies,
  that already enjoy huge network effects. @p{»»}

  @p{««}But... the potential users for Bitcoin is greater than any national
  currency because Bitcoin doesn't care about arbitrary political borders.
  So maybe at some point in the future a distributed, borderless
  crypto-currency will have a bigger network effect, and will start to
  replace zlotny or euros or dollars. @p{»»}

  @p{««}At that point, I don't think any one government would be able to
  compete. Other governments won't voluntarily give up the ability to
  control their own currency, so even if a government came out with their
  own crypto-currency how would they overcome the network effect and get
  people all over the world to use their newfangled solution? @p{»»}

  @p{««}It is possible that there will be some type of worldwide
  government; a currency from THAT government could, I think, compete with
  a decentralized crypto-currency. @p{»»}

  @p{««}I have no idea how likely any of this is. @p{»»}

  @p{««}RE: consequences of the dollar not being the world's reserve
  currency any more: I'd take a look at the history of Britain. The Pound
  was the world's reserve currency for a long time, before being replaced
  by the dollar. England seems to be doing OK, and I'm not aware of any
  radically huge consequences of the transition from Pounds to dollars.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1883}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 02:30:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128042.msg1398827@s{hash}msg1398827
@section 3 {tx}

  @s{quotedtext}

  @p{««}Ay carumba, how did we not notice that for over two years? @p{»»}

  @p{««}I introduced that bug with the 'sendmany' command two years ago
  (commit b9d1ed85). This is why programmers should not be trusted to test
  their own code (I probably carefully tested to make sure the change
  position looked random when I send to more than one destination, and
  never tested the degenerate send-to-one case; sigh). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1884}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 14:14:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130749.msg1399620@s{hash}msg1399620
@section 3 {tx}

  @p{««}CAs will issue you multi-domain certificates for not a WHOLE lot
  more than a single-domain certificate, which suggests to me a possible
  short-term workaround/hack until DNSSEC/DANE is widely deployed. @p{»»}

  @p{««}Get a certificate that is valid for these subdomains: @p{»»}

    @p{(li} merchant.com @p{li)}

    @p{(li} @s{(link)} @p{li)}

    @p{(li} BaseBitcoinAddress.merchant.com (e.g.
    1gavinR2Y6RiHnEbf3sJBGbbKTc5t66do.merchant.com ) @p{li)}

  @p{««}(in X.509 speak: Subject Alternative Names) @p{»»}

  @p{««}Payment requests from the merchant would include that certificate
  and the full public key (or script) that corresponds to
  1baseBitcoinAddress. @p{»»}

  @p{««}Bitcoin clients would have to notice that the merchant's SSL
  certificate included a bitcoin address as one of the top-level domains,
  and would need to reject any payment requests that didn't include the
  full public key/script (and would always pay to
  BaseBitcoinAddress*hash(payment_request) where '*" is whatever
  hierarchical deterministic wallet scheme we decide we like). @p{»»}

  @p{««} @p{hrule} Reasons not to do this or why it might not work: @p{»»}

  @p{««}* It is a hack. @p{brk} * domain names are not case-sensitive
  (GOOGLE.com and google.com are the same); bitcoin addresses are. @p{brk}
  * The extra cost to the merchant for the multi-domain cert might not be
  worth the incremental security benefit; if they have good monitoring
  (which they should), then they should detect an attacker's intrusion
  within minutes and so their potential loss might be tiny. @p{»»}

  @p{««} @p{hrule} Edited, to add references to relevant standards: @p{»»}

  @p{««}X.509 certificates for the Internet: @p{brk} @s{(link)} @p{»»}

  @p{««}Subdomain names must be less than 63 characters and start with a
  letter: @p{brk} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1885}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 14:37:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130456.msg1399657@s{hash}msg1399657
@section 3 {tx}

  @s{quotedtext}

  @p{««} What Mike said. @p{»»}

  @p{««}Building a new PKI infrastructure is most definitely out of scope
  right now. @p{»»}

  @p{««}But if somebody wants to spearhead an effort to get CAs to allow
  extra public keys in the certificates that they issue... that might be
  worthwhile. @p{»»}

  @p{««}Then again, maybe not@p{--} DNSSEC/DANE might make the CAs
  obsolete.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1886}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 15:28:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130819.msg1399721@s{hash}msg1399721
@section 3 {tx}

  @p{««}Bitcoin version 0.7.2 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a bug-fix minor release. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you were running on Linux with a version that might have been
  compiled @p{brk} with a different version of Berkeley DB (for example,
  if you were using an @p{brk} Ubuntu PPA version), then run the old
  version again with the -detachdb @p{brk} argument and shut it down; if
  you do not, then the new version will not @p{brk} be able to read the
  database files and will exit with an error. @p{»»}

  @p{««}Explanation of -detachdb (and the new "stop true" RPC command):
  @p{brk} The Berkeley DB database library stores data in both ".dat" and
  @p{brk} "log" files, so the database is always in a consistent state,
  @p{brk} even in case of power failure or other sudden shutdown. The
  @p{brk} format of the ".dat" files is portable between different @p{brk}
  versions of Berkeley DB, but the "log" files are not@p{--} even minor
  @p{brk} version differences may have incompatible "log" files. The
  @p{brk} -detachdb option moves any pending changes from the "log" files
  @p{brk} to the "blkindex.dat" file for maximum compatibility, but makes
  @p{brk} shutdown much slower. Note that the "wallet.dat" file is always
  @p{brk} detached, and versions prior to 0.6.0 detached all databases
  @p{brk} at shutdown. @p{»»}

  @p{««}Bug fixes @p{brk} @p{»»}

  @p{««}* Prevent RPC 'move' from deadlocking. This was caused by trying to
  lock the @p{»»}

    @p{(li}database twice. @p{li)}

  @p{««}* Fix use-after-free problems in initialization and shutdown, the
  latter of @p{»»}

    @p{(li}which caused Bitcoin-Qt to crash on Windows when exiting.
    @p{li)}

  @p{««}* Correct library linking so building on Windows natively works.
  @p{»»}

  @p{««}* Avoid a race condition and out-of-bounds read in block
  creation/mining code. @p{»»}

  @p{««}* Improve platform compatibility quirks, including fix for 100% CPU
  utilization @p{»»}

    @p{(li}on FreeBSD 9. @p{li)}

  @p{««}* A few minor corrections to error handling, and updated
  translations. @p{»»}

  @p{««}* OSX 10.5 supported again @p{»»}

  @p{««} Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Alex @p{brk} dansmith @p{brk} Gavin Andresen @p{brk} Gregory
  Maxwell @p{brk} Jeff Garzik @p{brk} Luke Dashjr @p{brk} Philip Kaufmann
  @p{brk} Pieter Wuille @p{brk} Wladimir J. van der Laan @p{brk} grimd34th
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1887}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 15:47:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130819.msg1399750@s{hash}msg1399750
@section 3 {tx}

  @s{quotedtext}

  @p{««}PGP links are on the bitcoin.org homepage; @s{(link)} will get it.
  @p{»»}

  @p{««}The source for the bitcoin.org homepage is at github, so you can
  get it from there, too: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}It is also stored at the MIT pgp keyserver under email
  '@p{(link}gavinandresen@s{at}gmail.com@p{link)}': @p{»»}

    @p{(li}@s{(link)};op=index 

# ----------------------------------------------------------------------
@section 2 {ms1888}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 16:27:27 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130430.msg1399806@s{hash}msg1399806
@section 3 {tx}

  @p{««}I'm planning on renting a house near Cairns, Australia from June
  until December of next year. @p{»»}

  @p{««}I'd love to be able to pay the deposit and rent in bitcoin. @p{»»}

  @p{««}I think paying for international vacation rentals could be a
  "killer application" for Bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1889}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-14 23:39:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130819.msg1400616@s{hash}msg1400616
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, that will be fixed in the 0.8 release. @p{»»}

  @p{««}If you think the single-send-not-randomizing-the-change-address-bug
  gives you significantly less privacy... well, you're probably wrong, it
  is easy to cluster addresses if you have the right network analysis
  tools. But you can workaround the bug by adding an extra output to all
  of your transactions (add a new receiving address and then click the
  'add recipient' button in on the Send Coins tab in Bitcoin-Qt and send
  some coins to yourself). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1890}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-17 16:24:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130764.msg1405222@s{hash}msg1405222
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes @p{--} 0/1-confirmation double spends are certainly possible. A
  successful 2-confirmation double-spend would be more interesting. I
  would love to see if real-network experience matches the theoretical
  results from Meni's paper.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1891}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-18 14:07:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131168.msg1407190@s{hash}msg1407190
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm feeling grumpy this morning, so my reaction is "good luck with
  that." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1892}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-18 15:07:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131389.msg1407276@s{hash}msg1407276
@section 3 {tx}

  @s{quotedtext}

  @p{««}There are now lots of PCs for sale for Bitcoin at bitcoinstore.com.
  You don't HAVE to sell your bitcoins to get a PC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1893}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-18 17:39:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131258.msg1407488@s{hash}msg1407488
@section 3 {tx}

  @p{««}Standard disclaimer first: I am often wrong. @p{»»}

  @p{««}But I've got a nagging feeling that all of the pure Proof-Of-X
  (where X != Work) systems would set up a dynamic of "the rich and
  powerful get more rich and more powerful." @p{»»}

  @p{««}The more coins you have, the more you get, as far as I can see in
  all of the proposed schemes (another disclaimer: I only vaguely pay
  attention to all of the Proof-of-X schemes, so feel free to tell me how
  I'm wrong). Seems to me that would end up being a destructive feedback
  loop, where your decentralized currency naturally gets more and more
  centralized over time. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1894}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-20 21:21:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130749.msg1412332@s{hash}msg1412332
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm liking the hack the more I think about it, too. Encoding a
  compressed public key (257 bits) in base32 would be 52 characters, which
  is comfortably less than the 63-character domain name limit. @p{»»}

  @p{««}Anybody buying a multi-domain (not wildcard) certificate sometime
  soon? I'm curious to find out if CA's blink if you ask them to issue a
  certificate valid for something like
  BTC8df4rfkbmeopl49vvfgkjgtimb84k9gtredsxfr9fekspclen493.mydomain.com
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1895}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-20 21:55:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=130456.msg1412412@s{hash}msg1412412
@section 3 {tx}

  @s{quotedtext}

  @p{««} On one hand: "Complexity is the enemy of security." Several PKIs
  in parallel is more complex. @p{»»}

  @p{««}On the other hand: "Security In Depth." Several PKIs in parallel
  could be more secure. But I'd insist that ALL PKI authentications MUST
  be successful, otherwise you're just giving an attacker the ability to
  attack the least secure PKI. It would be a mistake to show users a
  dialog box: @p{»»}

  @s{quotedtext}

  @p{««} BUT: I think it is unlikely people will be willing deploy and keep
  secure multiple PKI systems, and I think the incremental security is
  small, so I think the right decision here is Keep It Simple, Stupid.
  @p{»»}

  @p{««}For example, I re-ordered the fields of SignedPaymentRequest so the
  entire structure doesn't have to be in memory at once to be processed,
  which is a suggestion from somebody considering implementing the payment
  protocol on a very memory-constrained hardware device. There are real
  tradeoffs if we make this more complex. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1896}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-21 20:58:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131919.msg1414177@s{hash}msg1414177
@section 3 {tx}

  @s{quotedtext}

  @p{««}Exactly. @p{»»}

  @p{««}My priorities are: @p{»»}

  @p{(li}  Network Security  @p{li)}

    @p{(li}@p{(li} Network Scalability @p{li)} @p{(li} Network Stability
    @p{li)}

  @p{««}After those Big Three: @p{»»}

  @p{(li}  Wallet Security  @p{li)}

  @p{««}Usability of the reference implementation is not on my priority
  list. I believe the vast majority of users will (if they aren't already)
  use bitcoin via a web-based service or an app on their mobile phone.
  @p{»»}

  @p{««}RE: the bitcoin.org homepage: I think replacing the links to
  Bitcoin-Qt on the hompage with just a link to the clients page is a good
  idea. Somebody should get the consensus to do that and submit a pull
  request. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1897}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-21 22:59:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131919.msg1414368@s{hash}msg1414368
@section 3 {tx}

  @s{quotedtext}

  @p{««} No fork required. The secure payment protocol stuff is all
  higher-level than the blockchain. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1898}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-22 13:05:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131940.msg1415270@s{hash}msg1415270
@section 3 {tx}

  @s{quotedtext}

  @p{««}There are several smart people here who would tell you if your fix
  will work or not, if you listen to them. @p{»»}

  @p{««}Peer review is not perfect, but is much better than assuming that
  you will always come up with the best solution. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1899}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-26 18:13:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133319.msg1420883@s{hash}msg1420883
@section 3 {tx}

  @p{««}I sent ShadowOfHarbringer's some of my thoughts on this in this
  private message: @p{»»}

  @s{quotedtext}

  @p{««} I don't worry much right now about economically irrational, "I'm
  going to spend millions of dollars to disrupt the bitcoin network"
  attacks because I don't think anybody is going to spend millions of
  dollars to disrupt our tiny payment network. @p{»»}

  @p{««}I have no idea what bitcoin payments will look like in 5-10 years;
  I expect all sorts of trust mechanisms and relationships to develop that
  are independent of the bitcoin network, and I suspect some of those will
  make 51% attacks irrelevant. @p{»»}

  @p{««}And I have no idea what the mining landscape will look like in 5-10
  years; if thousands of companies around the world are installing bitcoin
  mining hardware for free in every house built in cold climates (generate
  bitcoins and get a discount on your heating bill) then it may be
  completely inconceivable for even a government to amass enough hashing
  power to mount a 51% attack. @p{»»}

  @p{««}So while I encourage y'all to keep thinking about it as an
  interesting theoretical problem, it is only slightly higher on my
  personal priority list than worrying about quantum computers breaking
  ECDSA. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1900}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-27 17:32:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133518.msg1422281@s{hash}msg1422281
@section 3 {tx}

  @p{««}There is a longstanding issue that might be related: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1901}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-28 02:49:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133490.msg1422920@s{hash}msg1422920
@section 3 {tx}

  @p{««}Planet Money has done some great podcasts on dollar coins. Start
  here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1902}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-28 21:09:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=115138.msg1423947@s{hash}msg1423947
@section 3 {tx}

  @p{««}The bitcoind sendmany RPC call uses destination addresses as JSON
  Object keys, so you can't send to the same address multiple times in one
  transaction. @p{»»}

  @p{««}If you REALLY want to do that... first, why do you want to do that?
  I suppose if you want to use the blockchain as a messaging system then
  sending 0.123+0.567+etc might be an inefficient way of sending a
  message... but please don't do that. @p{»»}

  @p{««}Anyway, if you do REALLY want to do that, you'll have to write code
  to construct the transaction yourself. Then you could pass it to the
  signrawtransaction/sendrawtransaction RPC methods to broadcast it. (you
  can't use createrawtransaction to create it, because it uses the same
  JSON syntax as sendmany for destination outputs). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1903}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2012-12-31 19:38:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134032.msg1428096@s{hash}msg1428096
@section 3 {tx}

  @p{««}How will you know if people tend to pick the same types of events,
  and, therefore, create big non-random clusters of choices that might be
  easily brute-forced? @p{»»}

  @p{««}Taking an idea from @s{(link)}... @p{»»}

  @p{««}.... you could store a small number of bitcoin at private key =
  SHA256(memory_key), store the bulk of bitcoin at
  scrypt(Name+PIN+memory_key), and tell users to choose a new memory key
  if the SHA256(memory_key) coins are either ever spent or if that key
  ever gets funds from somebody else. @p{»»}

  @p{««}Because that means somebody else chose the same memory key. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1904}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-02 20:01:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=132038.msg1430946@s{hash}msg1430946
@section 3 {tx}

  @p{««}Seems to me account credentials are a kind of intangible property,
  and selling stolen property is illegal and shouldn't be allowed in the
  forums. @p{»»}

  @p{««}I am not a lawyer, so that might not actually be true. But it seems
  to me that's the way the law should be, and the right thing to do. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1905}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-02 20:05:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133974.msg1430952@s{hash}msg1430952
@section 3 {tx}

  @p{««}So... maybe @s{(link)} needs some editing in the same spirit that
   he's editing other pages... @p{brk} @s{rolleyes} @p{»»}

  @p{««}(darn, nanotube protected it...) @p{brk} (ps to nanotube: that page
  should be deleted, in my humble opinion) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1906}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-02 21:18:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134078.msg1431095@s{hash}msg1431095
@section 3 {tx}

  @s{quotedtext}

  @p{««} That is ascii for 'script' @p{--} and was an unfortunate bug in
  somebody's software, if I recall correctly. @p{»»}

  @s{quotedtext}

  @p{««} Excellent! The first step to bitcoin development enlightenment is
  realizing that you are a part of the process... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1907}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-02 21:37:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134318.msg1431129@s{hash}msg1431129
@section 3 {tx}

  @p{««}In my experience, developers are really good at either ignoring
  documentation or interpreting it in a way different than the way the
  author intended. @p{»»}

  @p{««}And spec authors are really good at getting details wrong, no
  matter how careful they are. And they're really bad at keeping track of
  changes. @p{»»}

  @p{««}That's why I spent a lot of time over the past year developing test
  cases and tools that you can run your code against instead of writing
  specs. @p{»»}

  @p{««}I may just be cynical because I spent so much time in 1997 working
  on the ISO/IEC-14772-1 Official, Formal Standard. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1908}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-03 21:21:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131443.msg1433030@s{hash}msg1433030
@section 3 {tx}

  @p{««}theymos is correct; if all the inputs have a UINT_MAX sequence
  number then lockTime is ignored. @p{»»}

  @s{quotedtext}

  @p{««} Yes, they're supported by the network. @p{»»}

  @s{quotedtext}

  @p{««} No, there is no easy way to create such a transaction using the
  reference code. @p{»»}

  @p{««}* Super-duper-bitcoin-ninjas like gmaxwell who edit raw
  transaction hex to set lock times / sequence numbers don't count. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1909}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-04 03:33:49 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134569.msg1433557@s{hash}msg1433557
@section 3 {tx}

  @s{quotedtext}

  @p{««}Yes, those instructions should work, but build-osx.txt tells you
  how to build bitcoind. See @p{»»}

    @p{(li}@s{(link)} @p{li)} ... for very similar instructions on
  building Bitcoin-Qt @p{»»}

  @p{««}readme-qt.rst suggests downloading and installing the Qt Mac OS X
  SDK from the QT website, but you can also: @p{»»}

    @p{(li}port install qt4-mac @p{li)}

  @p{««}If something doesn't work, post here, or, even better, submit a
  patch for the documentation. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1910}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-06 16:35:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133832.msg1438068@s{hash}msg1438068
@section 3 {tx}

  @p{««}RE: "multisig transactions" : @p{»»}

  @p{««}I did some high-level multisig design work a couple of months ago:
  @p{»»}

    @p{(li}@s{(link)} @p{li)} and @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and had these thoughts about terminology: @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1911}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-06 16:48:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134318.msg1438091@s{hash}msg1438091
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because people like you noticed that it isn't quite right, but
  didn't bother to change it? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1912}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-06 16:57:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=134318.msg1438101@s{hash}msg1438101
@section 3 {tx}

  @p{««}I completely agree that more documentation is better, as long as
  you don't fall into the trap of "if the documentation says it it MUST be
  true." @p{»»}

  @p{««}Suggestions on how to make the wiki better welcome (there is a
  discussion elsewhere about banning certain people from the wiki because
  they have a history of starting edit wars, which I would support, and
  discussion on the Foundation forums about making the wiki infrastructure
  independend of Mt. Gox, which I also support). Or volunteers to move
  technical documentation from the wiki to someplace better also welcome.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1913}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-06 17:12:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=133832.msg1438121@s{hash}msg1438121
@section 3 {tx}

  @p{««}So @p{(bf}is@p{bf)} there a banking term for an account that
  requires multiple authorizations for spending? @p{»»}

  @p{««}I ain't never been a CFO or an accountant, so I don't know nuthin
  about that stuff... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1914}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-08 00:34:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=94155.msg1440523@s{hash}msg1440523
@section 3 {tx}

  @p{««}It wouldn't be hard to prototype a coin mixer using the raw
  transactions API and a centralized web service (accessible via Tor, if
  you're worried about it recording your IP address). @p{»»}

  @p{««}If you want to do a really good job, though, you'll need: @p{»»}

    @p{(li}@p{(li} Lots of people participating and/or @p{li)} @p{(li}
    Lots of time so your mixes are spread out over time @p{li)}

  @p{««}The 'lots of people' will take time, because the mixing code needs
  very high trust since it'll be spending your coins. @p{»»}

  @p{««}The 'lots of time' might be a practical problem, because the mixer
  needs your wallet to be unlocked so it can sign mixing transactions.
  @p{»»}

  @p{««}Somebody should create a working prototype and then for a Bitcoin
  Foundation grant to fund the web service for a year... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1915}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-08 21:02:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135379.msg1442290@s{hash}msg1442290
@section 3 {tx}

  @s{quotedtext}

  @p{««} As was pointed out, getrawtransaction @p{lt}txid@s{gt} 1 will do
  the decode for you. @p{»»}

  @p{««}If your JSON-RPC library supports it, you could also use a 'batch'
  request to get all of the inputs in one round-trip. See
  @p{(link}@s{(link)}@s{hash}batch@p{link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1916}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-08 21:22:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135406.msg1442338@s{hash}msg1442338
@section 3 {tx}

  @p{««}If you're interested in coin control, and you're comfortable with
  python and the command-line, then I could use your help. @p{»»}

  @p{««}I've written a little utility called 'spendfrom.py' that uses the
  raw transactions JSON-RPC api to send coins received on particular
  addresses that I'd like to ship in the contrib/ directory. @p{»»}

  @p{««}But since it touches the wallet it needs thorough testing. @p{»»}

  @p{««}I've written a test plan; who is willing to run through the test
  plan with their -testnet wallet and then try to break it? @p{»»}

  @p{««}Test plan: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @s{code}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1917}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-08 21:57:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135406.msg1442429@s{hash}msg1442429
@section 3 {tx}

  @p{««}If you've got easy_install (does OSX 10.6 comes with easy_install
  ?), then try: @p{»»}

  @p{««} easy_install jsonrpc @p{»»}

  @p{««}Or grab jgarzik's version from github: @p{»»}

    @p{(li} @s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1918}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-09 16:17:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135388.msg1444006@s{hash}msg1444006
@section 3 {tx}

  @p{««}Yes, please do a proof-of-concept on testnet. @p{»»}

  @p{««}I suspect this code in CTransaction::GetMinFee() makes the attacks
  either slower or more expensive than you estimate because fees increase
  for transactions larger than 250Kbytes: @p{»»}

  @s{code}

  @p{««} I don't think these vulnerabilities are serious enough to warrant
  Official CVE Numbers, because I think if we create CVE numbers for every
  expensive-to-mount, easy-to-recover-from DoS vulnerability we will be
  denial-of-service-ing the attention span of users, and they might start
  ignoring warnings. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1919}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-09 18:53:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135567.msg1444299@s{hash}msg1444299
@section 3 {tx}

  @p{««}There are three 0.5 BTC bounties available for people who will help
  us test the upgrade-to-release-0.8 code. @p{»»}

  @p{««}I'm looking for: @p{»»}

  @p{««}CLAIMED: @p{(so}Somebody running (or willing to install and
  sync-up) bitcoind/bitcoin-qt version 0.3.24 @p{brk} (need to test
  upgrading from a very old version of Bitcoin)@p{so)} @p{»»}

  @p{««}CLAIMED: @p{(so}Somebody running a version of Windows with their
  bitcoin data directory on a FAT32 filesystem @p{brk} (need to test
  upgrading on a very old filesystem)@p{so)} @p{»»}

  @p{««}CLAIMED: @p{(so}Somebody running Windows XP with an NTFS filesystem
  @p{brk} (need to test upgrading on a very old operating system) @p{brk}
  @p{so)} @p{»»}

  @p{««}Detailed instructions on how to test and then claim a bounty are
  here: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1920}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-09 21:48:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135567.msg1444630@s{hash}msg1444630
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you're right, 0.3.24 does not support -logtimestamps. If I
  recall correctly, it does log the time at startup; for this particular
  test, I'm mostly interested in how long the upgrade process takes, so
  the old version not supporting timestamps isn't a problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1921}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-10 18:16:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135406.msg1446419@s{hash}msg1446419
@section 3 {tx}

  @s{quotedtext}

  @p{««} Thanks for helping test! Latest version fixes the p2sh issue.
  @p{»»}

  @p{««}I had it 4-decimal-places because I personally don't care about
  less than 0.0001 BTC right now. It is 8 now, just because I know you
  won't be the last person to ask "why does it round." @p{»»}

  @s{quotedtext}

  @p{««} If there are python command-line-tool packaging experts,
  suggestions on how to package this better are welcome. I thought all
  versions of jsonrpc had a ServiceProxy class, but I guess I'm wrong.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1922}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-10 18:51:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135406.msg1446492@s{hash}msg1446492
@section 3 {tx}

  @p{««}Dunno why github says 'authored 6 days ago', commit 2e922 was
  pushed yesterday and definitely has the changes (see lines 107-108 of
  spendfrom.py). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1923}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-10 21:29:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=8558.msg1446767@s{hash}msg1446767
@section 3 {tx}

  @p{««}correction: bitcoin-qt/bitcoind command-line arguments have a
  single-dash, so it would be @p{»»}

    @p{(li}bitcoin-qt -server @p{li)}

  @p{««}Since you have to set a rpcuser/rpcpassword in the bitcoin.conf
  file for -server to work anyway, you might want to put "server=1" in the
  bitcoin.conf file instead of using the command-line argument... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1924}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-11 04:38:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135856.msg1447313@s{hash}msg1447313
@section 3 {tx}

  @p{««}While we ponder this, if you are worried about this, there is a
  fairly straightforward workaround that will make you immune from this.
  @p{»»}

  @p{««}Run two bitcoin daemons. One that is a full peer in the network,
  but has an empty, never-used wallet. @p{»»}

  @p{««}And another with a full wallet that connects to the full peer. You
  could even run them both on the same machine (you'll use double the CPU
  and disk space, unfortunately). @p{»»}

  @p{««}RE: "I better alert people before they can be tracked" : @p{»»}

  @p{««}Dan Kaminsky demonstrated that it is pretty easy to tie bitcoin
  addresses to IP addresses by watching the network last year. If you are
  worried about being tracked, you should be running bitcoin over Tor and
  connecting to only trusted nodes. We make no anonymity guarantees. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1925}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-12 21:39:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=4571.msg1450235@s{hash}msg1450235
@section 3 {tx}

  @s{quotedtext}

  @p{««} The only completely and utterly decentralized bitcoin-like system
  I can think of would have every person using it write and run their own
  code. @p{»»}

  @p{««}On computers that they built themselves. @p{»»}

  @p{««}Communicating over a wireless mesh network where each node in the
  mesh was controlled by a single person who wrote all the code and built
  all the hardware.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1926}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-16 16:37:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=136795.msg1457862@s{hash}msg1457862
@section 3 {tx}

  @p{««}Successful technology companies do not waste their time solving
  problems that they THINK they MIGHT have in 20 years. @p{»»}

  @p{««}They don't even spend much time thinking about problems that they
  might have in four years. @p{»»}

  @p{««}I don't spend any time worrying about the strength of 256-bit ECDSA
  or 160-bit RIPEMD, and I spend even less time worrying about the
  strength of those two combined. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1927}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-17 16:11:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=136795.msg1460212@s{hash}msg1460212
@section 3 {tx}

  @s{quotedtext}

  @p{««} Let me google that for you.... ah, here's a nice chart: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}There is about 5 trillion dollars in currency in the world. @p{»»}

  @p{««}So 2.1 thousand trillion satoshis is @p{(bf}PLENTY@p{bf)}. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1928}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-18 01:04:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135567.msg1461393@s{hash}msg1461393
@section 3 {tx}

  @p{««}Oops, sorry, update the github page, all the bounties are claimed.
  @p{»»}

  @p{««}Thanks to everybody who tested, you were extremely helpful. @p{»»}

  @p{««}What did you think about the bounty amounts: too much? too little?
  just right? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1929}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-21 20:47:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=137729.msg1468842@s{hash}msg1468842
@section 3 {tx}

  @p{««}With the current transaction fee rules, inputs of less than about
  0.00005 BTC will cost more to spend than they are worth. @p{»»}

  @p{««}(somebody check my arithmetic, I'm good at dropping digits:
  MIN_TX_FEE is 0.0005 BTC per kilobyte, an extra input is a
  signature+pubkey+a few extra bytes = 100 bytes, so minimum fee per input
  is about 0.00005 BTC) @p{»»}

  @p{««}Wallet software should probably display micro-inputs as zero to the
  user (they really are worthless right now, since they cost more to spend
  than they are worth) and ignore them when computing the wallet balance
  or getting inputs to spend. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1930}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-21 21:48:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=137729.msg1468954@s{hash}msg1468954
@section 3 {tx}

  @s{quotedtext}

  @p{««} But a transaction with a 0.005 BTC output triggers this rule:
  @p{»»}

  @p{««}Code: // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if
  any output is less than 0.01 @p{brk} ... so you're back to paying
  10kilobytes * 0.0005 BTC / kilobyte == 0.005 BTC to spend those 0.005
  BTC. @p{»»}

  @p{««}Yes, if you have a large-value, well-aged input then you can
  combine it with tiny transactions, have a single output greater than
  0.01 BTC, and probably get into a block for free. @p{»»}

  @p{««}If you want to prototype a smarter coin-selection algorithm, you
  might start with the 'spendfrom.py' code I wrote as an example of using
  the raw transactions API: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1931}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-21 22:18:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=6785.msg1469004@s{hash}msg1469004
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... and because bitcoind's wallet code hasn't been optimized for
  massive wallets. "patches welcome" @p{brk} (although I think the wallet
  code needs a complete rewrite, we've learned a lot over the last couple
  of years and need wallets that are much easier to back up and keep
  secure). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1932}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-22 15:03:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=137811.msg1470632@s{hash}msg1470632
@section 3 {tx}

  @p{««}I started working through a GUI design for secure multi-device
  wallets a couple months ago: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}But to be secure, I think we need the @p{(link}payment
  protocol@p{link)} first, because otherwise an attacker can simply
  replace the bitcoin address given to the first device and trick you into
  paying them.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1933}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-22 22:14:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=137866.msg1471782@s{hash}msg1471782
@section 3 {tx}

  @p{««}RE: what's my role in the core team: I try to do whatever needs to
  get done, that isn't getting done. Today I'm cross-compiling the 0.8
  release and testing it on Windows, trying to track down a crash-at-exit
  issue and an excessive-memory-use issue that seems to only happen on
  Windows. @p{»»}

  @p{««}When I'm not doing nitty-gritty things like that, I try to work on
  big, what-is-most-likely-to-make-Bitcoin-succeed problems. @p{»»}

  @p{««}RE: why pay me a salary? "why pay for the cow if you can get the
  milk for free?" @p{»»}

  @p{««}I told myself (and my wife) a couple of years ago that I wasn't
  going to sink dollars into Bitcoin@p{--} that I'd sink time into it, and
  that I'd EARN bitcoins by starting a bitcoin-related startup. @p{»»}

  @p{««}Well, there's enough core development work to keep me busy full
  time. I wasn't very happy doing core development work AND trying to make
  ClearCoin happen; I'm happier when I can concentrate on one thing.
  Besides, having my own startup introduces potential conflicts of
  interest (ClearCoin sparked conspiracy theories about why I push for
  multisig transactions so hard). @p{»»}

  @p{««}RE: what if I get hit by a bus? @p{»»}

  @p{««}Then the other core developers will carry on without me. I'm not
  indispensable. @p{»»}

  @p{««}RE: Why should you join the Foundation? What is in it for you,
  personally? @p{»»}

  @p{««}That is a hard question, because you can "free ride" @p{--} if
  we're successful making Bitcoin successful, everybody will benefit.
  Personally, I don't respect people with that kind of "I'm not going to
  do it because I'm sure somebody else will" attitude, and I think in the
  long run the people who take the risks and roll up their sleeves and do
  the work needed tend to win in the end. @p{»»}

  @p{««}Really, the main benefit of joining the Foundation is it is an
  organization full of people who @p{(bf}are@p{bf)} rolling up their
  sleeves and doing the work. If you're smart, you'll realize that
  networking with those types of people is to your long-term benefit.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1934}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-22 23:05:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=138000.msg1471895@s{hash}msg1471895
@section 3 {tx}

  @s{quotedtext}

  @p{««} "sort of expensive" ? Really expensive and getting more expensive
  all the time. And absolutely impossible for a lightweight hardware or
  mobile-phone wallet, which I think a lot of people will use as their
  second-factor device. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1935}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-23 04:09:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=137499.msg1472407@s{hash}msg1472407
@section 3 {tx}

  @p{««}I think Dev&amp;Tech == generic technical discussion, then
  sub-forums for discussion of development of the popular clients makes
  sense (including 'Reference Client (Bitcoin-Qt/bitcoind)' ). And a
  catch-all for any not-yet-popular (or used-to-be-popular) clients. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1936}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-24 02:51:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=126024.msg1474773@s{hash}msg1474773
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is very high on the priority list, yes. Miners already support
  it, but there are still a couple of steps to go before you can create a
  wallet split between Bitcoin-Qt running on your desktop computer and an
  app running on your iPhone. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1937}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-24 13:21:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=138028.msg1475761@s{hash}msg1475761
@section 3 {tx}

  @p{««}20.11 

# ----------------------------------------------------------------------
@section 2 {ms1938}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-25 20:49:45 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=138752.msg1479445@s{hash}msg1479445
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. It is perfectly possible for multiple people to provide inputs
  to a transaction, each signing their input but without knowledge of the
  other people's keys. @p{»»}

  @p{««}That is extremely rare now, but that is exactly what you would do
  to implement a peer-to-peer coin-mixing service, which I suspect may be
  a very popular way of paying for things since it increases your privacy
  significantly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1939}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-26 19:56:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=135985.msg1481577@s{hash}msg1481577
@section 3 {tx}

  @p{««}The reference implementation patch is scheduled for the (real soon
  now!) 0.8 release: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1940}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-27 23:49:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139390.msg1484096@s{hash}msg1484096
@section 3 {tx}

  @p{««}Humans are pretty bad at being original. REALLY bad at being
  random. And we are terrible at comprehending huge numbers. @p{»»}

  @p{««}So if you ask the average person to create a secure passphrase,
  they're very likely to create something that a "determined attacker"
  with a lot of computing power can crack. @p{»»}

  @p{««}I think if people start to use quotes from obscure literary works
  as their brain wallets, then they're going to lose their bitcoins sooner
  or later. Attackers can try MILLIONS of passphrases per minute, to crack
  EVERY SINGLE brainwallet that has ever been created. @p{»»}

  @p{««}So: if you absolutely, positively won't be dissuaded from using a
  brainwallet, here is my advice on how you @p{(it}might@p{it)} be able to
  come up with a secure passphrase: @p{»»}

  @p{««}Think of two passphrases that you think you can remember. And think
  of a government-issued number that you can easily lookup or remember
  (like your driving license or social security number). @p{»»}

  @p{««}Create a brainwallet passphrase that is: @p{»»}

  @p{««}the first passphrase,the government id number,the second passphrase
  @p{»»}

  @p{««}Then create a 'sentinel' brainwallet that is just the first
  passphrase, and send a small number of bitcoins to it. When those
  bitcoins get spent (or more bitcoins are sent to it by somebody else),
  you know that the first passphrase you chose isn't good enough any more.
  Choose a more complicated passphrase and create a new 'sentinel' and
  real brainwallet, and move your old brainwallet there. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1941}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-28 02:02:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139390.msg1484278@s{hash}msg1484278
@section 3 {tx}

  @s{quotedtext}

  @p{««}Because it is critical that YOUR passphrase be different from
  EVERYBODY ELSE'S passphrase. @p{»»}

  @p{««}Adding your email address or driver's license number or some other
  certainly-unique-for-you information makes that work. @p{»»}

  @p{««}That shifts the problem from "attacker is trying to guess
  EVERYBODY's passphrase" to "attacker happens to know that you have a
  bunch of BTC in a brainwallet and is trying to attack YOUR brainwallet,
  specifically." @p{»»}

  @s{quotedtext}

  @p{««} Nicely said. @p{»»}

  @p{««}Again: we are really bad at thinking up good, unique passphrases.
  We share so much experience and culture that whatever you think of,
  somebody else will probably think of, too. Or some attacker will think
  of something similar enough to crack your passphrase. @p{»»}

  @p{««}And we are really bad at imaging what it means that an attacker
  might try a few hundred BILLION passphrases to try to crack everybody's
  brainwallet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1942}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-28 18:48:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139443.msg1485749@s{hash}msg1485749
@section 3 {tx}

  @p{««}Is there a lot of demand for timestamping? Are people willing to
  pay for it? @p{»»}

  @p{««}There are already free, centralized services that will timestamp
  arbitrary hashes for you. Besides the risk that they might go away
  (which you could mitigate by getting timstamps from several of them), is
  there any real advantage to using the blockchain? @p{»»}

  @p{««}If I can already get timestamps for free, why would I bother to pay
  a transaction fee to get a blockchain timestamp? @p{»»}

  @p{««}I'm often wrong, so feel free to ignore me, but blockchain
  timestamping seems to me like one of those gee-whiz ideas that appeals
  to us techies but isn't "enough better" than existing solutions to be
  interesting to non-techies. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1943}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-28 18:49:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139443.msg1485752@s{hash}msg1485752
@section 3 {tx}

  @s{quotedtext}

  @p{««} .... another random thought: I wouldn't be surprised if you could
  get tricky with nonces to get any https-enabled web server to act as a
  free timestamping service, too... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1944}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-28 21:12:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139512.msg1486131@s{hash}msg1486131
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'd just point them to @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1945}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-29 16:45:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139390.msg1488185@s{hash}msg1488185
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't think anybody knows. But you can find out: @p{»»}

  @p{««}Send a token amount of bitcoin to two more brainwallets, made from
  each of the sentences. @p{»»}

  @p{««}When somebody else either spends those bitcoins or sends more
  bitcoins to them, you know that your main brainwallet isn't safe any
  more. (are the services that will send you an email when there is
  activity on a bitcoin address still around?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1946}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-29 17:21:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139702.msg1488287@s{hash}msg1488287
@section 3 {tx}

  @s{quotedtext}

  @p{««} Run a testnet node and turn on CPU mining. We need more stable,
  long-running -testnet nodes. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1947}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-30 14:29:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=139390.msg1490312@s{hash}msg1490312
@section 3 {tx}

  @p{««}Okey dokey, first I think @p{(bf}nobody should use an
  easy-to-memorize brainwallet@p{bf)} for anything more than
  experimenting. I predict we'll start seeing very unhappy brainwallet
  users reporting huge losses sooner or later. @p{»»}

  @p{««}Second: the 'sentinel wallet' idea is all about incentives. @p{»»}

  @p{««}You need to put enough BTC in the sentinel wallet so it is
  economically rational for an attacker to "take the money and run" rather
  than spend time and money trying to crack a bigger brainwallet that
  might not even exist. @p{»»}

  @p{««}Again, I don't think you should use a brainwallet, so I'm not
  motivated to do the math to figure out how many BTC you should put into
  the sentinel wallet so a ration attacker will just take it, but that is
  the way you should think about it.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1948}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-30 21:50:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140078.msg1491378@s{hash}msg1491378
@section 3 {tx}

  @p{««}Thanks Sergio! @p{»»}

  @p{««}So: if the attacker creates a block with a transaction that takes 3
  minutes to verify, and then broadcasts it, it will take a very long time
  for it to propagate across the network (because peers verify blocks
  before relaying them). @p{»»}

  @p{««}And since this attack requires non-standard transactions, mining a
  block is the only way an attacker will be able to pull off this attack.
  So I don't think this is a practical attack on the production network:
  by the time the 3-minute-to-verify block got to 50% of the network the
  other half of the network will probably have produced a block (sure, the
  attacker could try to Sybil the network and send its block to a
  super-majority of mining nodes, but I bet all of the big mining pools
  are hiding their block-creating and share-accepting nodes behind
  multiple "front-end bitcoinds" by now to mitigate DDoS attacks). @p{»»}

  @p{««}Fixing the OP_*SIG opcodes so they "look before they hash" is a
  good idea. We're actually moving towards that; see fStrictEncodings and
  the IsCanonicalSignature/IsCanonicalPubKey in the latest script.cpp
  code. The intent is to eventually roll out a 'soft-fork' that requires
  signatures and public keys be well-formed and canonical. @p{»»}

  @p{««}Also, a nit: using OP_0 for the scriptSig wouldn't work for this
  attack (see if (vchSig.empty()) return false; in CheckSig()). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1949}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-30 21:56:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140057.msg1491408@s{hash}msg1491408
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1950}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-01-31 18:56:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140313.msg1493954@s{hash}msg1493954
@section 3 {tx}

  @p{««}Starting now! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1951}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-01 01:26:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140078.msg1494724@s{hash}msg1494724
@section 3 {tx}

  @p{««}Sergio: @p{»»}

  @p{««}It @p{(bf}would@p{bf)} be more helpful if you either took a little
  bit more time and actually wrote a little bit of code to make sure the
  attack works, and started the conversation privately with "here's code
  that demonstrates a very expensive-to-verify transaction and a few
  suggestions on how you might fix it..." @p{»»}

  @p{««}I created a simulation of TxPrep/TxAttack by adding them to
  src/test/data/script_valid.json and then running through the
  script_tests.cpp unit test in the debugger, and with the particular
  TxPrep you propose there is no problem with current code. @p{»»}

  @p{««}Also, TxAttack is not standard with the latest code; see
  CTransaction::AreInputsStandard(), which checks the scriptPubKeys being
  spent. @p{»»}

  @p{««}RE: undocumented process of responsible disclosing : good point.
  Where would you expect to find the process documented? We can fix
  that... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1952}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-01 20:30:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140233.msg1496306@s{hash}msg1496306
@section 3 {tx}

  @p{««}For the record: @p{»»}

  @p{««}I'm on the "let there be no fixed maximum block size" side of the
  debate right now. @p{»»}

  @p{««}I think we should let miners decide on the maximum size of blocks
  that they'll build on. I'd like to see somebody come up with a model for
  time-to-transmit-and-receive-and-validate-a-block versus
  increased-chance-that-block-will-be-an-orphan. @p{»»}

  @p{««}Because that is the tradeoff that will keep miners from producing 1
  Terabyte blocks (or, at least, would keep them from producing 1 Terabyte
  blocks right now@p{--} if we have petabyte thumb-drives and
  Terabyte/second networks in 10 years maybe 1Terabyte blocks will be just
  fine). @p{»»}

  @p{««}Right now, miners that use the reference implementation and don't
  change any settings will produce blocks no larger than 250Kbytes big.
  @p{»»}

  @p{««}So we're finding out right now how miners collectively react to
  bumping up against a block size limit. I'd like to let that experiment
  run for at least a few months before arguing that we do or do not need
  to eliminate the 1MB hard limit, and start arguing about what the
  default rules for acceptable block size should be. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1953}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-01 20:41:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140313.msg1496336@s{hash}msg1496336
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yeah@p{--} "democratic" is such a loaded word. Everybody loves
  democracy, so I didn't want to bash it. @p{»»}

  @p{««}But democracy can be terrible if you're in the minority and the
  majority decides to trample on your rights. @p{»»}

  @p{««}I probably should have just said "Bitcoin is a lot more democratic
  than the system we currently have, where a handful of unelected central
  bankers control our money." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1954}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-02 22:01:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140233.msg1499229@s{hash}msg1499229
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ummm, see @p{(link}this old forum thread@p{link)}, where Satoshi
  says: @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1955}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-04 17:17:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140233.msg1503099@s{hash}msg1503099
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think this is exactly the right thing to do. @p{»»}

  @p{««}There is still the question of what the default behavior should be.
  Here is a proposal: @p{»»}

  @p{««}Ignore blocks that take your node longer than N seconds to verify.
  @p{»»}

  @p{««}I'd propose that N be: 60 seconds if you are catching up with the
  blockchain. 5 seconds if you are all caught-up. But allow
  miners/merchants/users to easily change those defaults. @p{»»}

  @p{««}Rationale: we should use time-to-verify as the metric, because
  everything revolves around the 10-minutes-per-block constant. @p{»»}

  @p{««}Time-to-verify has the nice property of scaling as hardware gets
  more powerful. Miners will want to create blocks that take a reasonable
  amount of time to propagate through the network and verify, and will
  have to weigh "add more transactions to blocks" versus "if I add too
  many, my block will be ignored by more than half the network." @p{»»}

  @p{««}Time-to-verify also has the nice property of incentivizing miners
  to broadcast transactions instead of 'hoarding' them, because
  transactions that are broadcast before they are in a block make the
  block faster to verify (because of the signature cache). That is good
  for lots of reasons (early detection of potential double-spends and
  spreading out the verification work over time so there isn't a blizzard
  of CPU work that needs to be done every time a block is found, for
  example). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1956}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-07 16:50:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=141536.msg1510238@s{hash}msg1510238
@section 3 {tx}

  @s{quotedtext}

  @p{««} The @p{(link}payment protocol@p{link)} (or a simple extension of
  it) is intended to be that more-flexible, standardized protocol. @p{»»}

  @s{quotedtext}

  @p{««} Excellent! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1957}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-07 22:46:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=2623.msg1510975@s{hash}msg1510975
@section 3 {tx}

  @p{««}I'm of the opinion that bitcoind/Bitcoin-Qt shouldn't be pushed to
  the central/canonical repos until we hit version 1.0. @p{»»}

  @p{««}Until then, I think we change too much too often (e.g. the
  blockchain format completely changed in the 0.8 release, and the wallet
  format will likely be changed before we hit version 1.0). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1958}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-07 22:57:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=141865.msg1510995@s{hash}msg1510995
@section 3 {tx}

  @p{««}Got a fantastic idea for a project, but need some BTC to make it
  happen? @p{»»}

  @p{««}Apply for a grant from the Bitcoin Foundation: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Deadline is February 15'th. @p{»»}

  @p{««}Good grant proposals are for things that are clearly a benefit to
  the whole Bitcoin ecosystem and that are the kind of "common good" thing
  that doesn't have a clear business plan. (if you have an idea with a
  clear business plan then you should talk to an angel investor or venture
  capitalist to get some funding). @p{»»}

  @p{««}Examples (I'm sure you can think of better): @p{»»}

  @p{««} @p{(li}I'd love to see somebody run a free input-mixing service. A
  grant could cover server costs to run a server that takes connections
  over tor to coordinate mixes.@p{li)}

    @p{(li}Know any economists? A grant could pay to write some tools to
    extra bitcoin transaction data for an enterprising economist who might
    want to study the Bitcoin economy.@p{li)}

    @p{(li}There have been some very interesting research papers
    suggesting possible changes to core Bitcoin. A grant might pay for
    somebody to actually implement the ideas and demonstrate them on the
    -testnet.@p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1959}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-08 03:38:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=141879.msg1511465@s{hash}msg1511465
@section 3 {tx}

  @s{quotedtext}

  @p{««} The magic of public key crypto is that you can give somebody your
  public key, some data, and a signature, and they can be certain that:
  @p{»»}

  @p{««}a) that particular signature could only have been created by
  somebody that has the private key that corresponds to the public key
  @p{brk} b) the data hasn't been changed in any way @p{»»}

  @p{««}They don't need to know the private key@p{--} you keep it secret.
  @p{»»}

  @p{««}The "hash over..." bit is the way digital signatures work@p{--} you
  sign a hash of the data, and not the data itself, because the hash is
  much smaller. @p{»»}

  @p{««}The "...simplified version of the transaction" bit is complicated.
  The data signed is the transaction minus all it's scriptSig signatures,
  plus (almost always) the previous transaction's scriptPubKey. See the
  OP_CHECKSIG page on the wiki for all the gory details. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1960}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-09 15:52:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=142151.msg1514426@s{hash}msg1514426
@section 3 {tx}

  @p{««}Bitcoin version 0.8.0 release candidate 1 is now available from:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a major release designed to improve performance and handle
  the @p{brk} increasing volume of transactions on the network. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Release-candidate 1 notes: @p{»»}

  @p{««}The OSX binary reports its version as "0.8.0rc1-1-gba1d080-beta"
  due to @p{brk} issue @s{(link)} . This will be fixed @p{brk} before the
  final 0.8.0 release. @p{»»}

  @p{««}The Windows binaries could not be reproducibly built, due to issue
  @p{brk} @s{(link)} . This will also be fixed @p{brk} before the final
  0.8.0 release. The rc1 Windows binaries were built @p{brk} by me
  (Gavin). @p{»»}

  @p{««}How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or bitcoin-qt (on
  Linux). @p{»»}

  @p{««}The first time you run after the upgrade a re-indexing process will
  be @p{brk} started that will take anywhere from 30 minutes to several
  hours, @p{brk} depending on the speed of your machine. If you have
  enough @p{brk} memory, running with the -dbcache setting (e.g.
  -dbcache=1000 ) @p{brk} may make re-indexing faster. @p{»»}

  @p{««}Special notes for release candidate 1: @p{»»}

  @p{««}If you helped test pre-release versions, there are two changes that
  you @p{brk} should be aware of: @p{»»}

    @p{(li} 1. Subdirectories in the data directory changed names; to
  avoid re-indexing @p{brk} the blockchain, rename: @p{li)}

    @p{(li}mkdir $DATADIR/blocks &amp;&amp; mv $DATADIR/blktree
    $DATADIR/blocks/index @p{li)}

    @p{(li}mv $DATADIR/coins $DATADIR/chainstate @p{li)}

    @p{(li} 2. The "undo file" format changed; if you see errors at
  startup during block @p{brk} validation re-run with the -reindex flag to
  fix them. @p{li)}

  @p{««}Incompatible Changes  @p{»»}

  @p{««}This release no longer maintains a full index of historical
  transaction ids @p{brk} by default, so looking up an arbitrary
  transaction using the getrawtransaction @p{brk} RPC call will not work.
  If you need that functionality, you must run once @p{brk} with
  -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
  @p{brk} details). @p{»»}

  @p{««}Improvements @p{»»}

  @p{««}Mac and Windows binaries are signed with certificates owned by the
  Bitcoin @p{brk} Foundation, to be compatible with the new security
  features in OSX 10.8 and @p{brk} Windows 8. @p{»»}

  @p{««}LevelDB, a fast, open-source, non-relational database from Google,
  is @p{brk} now used to store transaction and block indices. LevelDB
  works much better @p{brk} on machines with slow I/O and is faster in
  general. Berkeley DB is now only @p{brk} used for the wallet.dat file
  (public and private wallet keys and transactions @p{brk} relevant to
  you). @p{»»}

  @p{««}Pieter Wuille implemented many optimizations to the way
  transactions are @p{brk} verified, so a running, synchronized node uses
  much less memory and does @p{brk} much less I/O. He also implemented
  parallel signature checking, so if you @p{brk} have a multi-CPU machine
  all CPUs will be used to verify transactions. @p{»»}

  @p{««}New Features @p{brk} @p{»»}

  @p{««}"Bloom filter" support in the network protocol for sending only
  relevant transactions to @p{brk} lightweight clients. @p{»»}

  @p{««}contrib/verifysfbinaries is a shell-script to verify that the
  binary downloads @p{brk} at sourceforge have not been tampered with. If
  you are able, you can help make @p{brk} everybody's downloads more
  secure by running this occasionally to check PGP @p{brk} signatures
  against download file checksums. @p{»»}

  @p{««}contrib/spendfrom is a python-language command-line utility that
  demonstrates @p{brk} how to use the "raw transactions" JSON-RPC api to
  send coins received from particular @p{brk} addresses (also known as
  "coin control"). @p{»»}

  @p{««}New/changed settings (command-line or bitcoin.conf file) @p{»»}

  @p{««}dbcache : now controls LevelDB memory usage. Running with (for
  example) -dbcache=1000 @p{brk} will use a gigabyte of memory and might
  make the initial blockchain download faster. @p{»»}

  @p{««}par : controls how many threads to use to validate transactions.
  Defaults to the number @p{brk} of CPUs on your machine, use -par=1 to
  limit to a single CPU. @p{»»}

  @p{««}txindex : maintains an extra index of old, spent transaction ids so
  they will be found @p{brk} by the getrawtransaction JSON-RPC method.
  @p{»»}

  @p{««}reindex : rebuild block and transaction indices from the downloaded
  block data. @p{»»}

  @p{««}New JSON-RPC API Features @p{brk} @p{»»}

  @p{««}lockunspent / listlockunspent allow locking transaction outputs for
  a period of time so @p{brk} they will not be spent by other processes
  that might be accessing the same wallet. @p{»»}

  @p{««}addnode / getaddednodeinfo methods, to connect to specific peers
  without restarting. @p{»»}

  @p{««}importprivkey now takes an optional boolean parameter (default
  true) to control whether @p{brk} or not to rescan the blockchain for
  transactions after importing a new private key. @p{»»}

  @p{««}Important Bug Fixes @p{brk} @p{»»}

  @p{««}Privacy leak: the position of the "change" output in most
  transactions was not being @p{brk} properly randomized, making network
  analysis of the transaction graph to identify @p{brk} users' wallets
  easier. @p{»»}

  @p{««}Zero-confirmation transaction vulnerability: accepting
  zero-confirmation transactions @p{brk} (transactions that have not yet
  been included in a block) from somebody you do not @p{brk} trust is
  still not recommended, because there will always be ways for attackers
  to @p{brk} double-spend zero-confirmation transactions. However, this
  release includes a bug @p{brk} fix that makes it a little bit more
  difficult for attackers to double-spend a @p{brk} certain type
  ("lockTime in the future") of zero-confirmation transaction. @p{»»}

  @p{««}Dependency Changes @p{»»}

  @p{««}Qt 4.8.3 (compiling against older versions of Qt 4 should continue
  to work) @p{»»}

  @p{««} Thanks to everybody who contributed to this release: @p{»»}

  @p{««}Alexander Kjeldaas @p{brk} Andrey Alekseenko @p{brk} Arnav Singh
  @p{brk} Christian von Roques @p{brk} Eric Lombrozo @p{brk} Forrest
  Voight @p{brk} Gavin Andresen @p{brk} Gregory Maxwell @p{brk} Jeff
  Garzik @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Mike Cassano
  @p{brk} Mike Hearn @p{brk} Peter Todd @p{brk} Philip Kaufmann @p{brk}
  Pieter Wuille @p{brk} Richard Schwab @p{brk} Robert Backhaus @p{brk}
  Rune K. Svendsen @p{brk} Sergio Demian Lerner @p{brk} Wladimir J. van
  der Laan @p{brk} burger2 @p{brk} default @p{brk} fanquake @p{brk}
  grimd34th @p{brk} justmoon @p{brk} redshark1802 @p{brk} tucenaber
  @p{brk} xanatos 

# ----------------------------------------------------------------------
@section 2 {ms1961}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-10 18:06:42 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=142151.msg1516986@s{hash}msg1516986
@section 3 {tx}

  @p{««}The crash-on-exit bug could be this issue: @s{(link)} @p{»»}

  @p{««}We may have to live with it for the 0.8 release, and fix it in the
  next release, because there is a high risk that fixing it will cause
  more problems than it solves. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1962}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-15 04:59:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=142151.msg1529545@s{hash}msg1529545
@section 3 {tx}

  @p{««}The windows setup.exe is signed, as is the Mac .app bundle. The
  executables inside them are not signed (I can't think of a good reason
  to sign them, it would not increase download security at all). @p{»»}

  @p{««}You can also still check the download packages using the
  SHASUMS.asc file, which is signed with my gpg key. @p{»»}

  @p{««}And if you are running Linux or Windows you could check all of the
  files in the installer against other core developer's keys. @p{»»}

  @p{««}If the code signing certificate was revoked then we would go back
  to just using gpg keys. The code signing certificate is great because
  Windows and OSX know how to check it automatically when the download
  happens.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1963}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-15 14:00:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144295.msg1530454@s{hash}msg1530454
@section 3 {tx}

  @s{quotedtext}

  @p{««} I hereby encourage everybody to use tor. @p{»»}

  @p{««}But I think worrying about thugs getting your street address from
  your Internet service provider and then breaking into your house to try
  to coerce you into giving them your Bitcoins seems very unlikely.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1964}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-15 23:52:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144421.msg1531776@s{hash}msg1531776
@section 3 {tx}

  @p{««}Why do people include transaction fees? @p{»»}

  @p{««}Assuming the miner hasn't tweaked the reference code's parameters,
  the rules are: @p{»»}

  @p{««}Create at most a 250,000 byte block: @p{»»}

    @p{(li}@p{(li} 27 kilobytes of space is set aside for the
    highest-priority transactions, regardless of fee. @p{li)} @p{(li} 223k
    of space left for fee-paying transactions. @p{li)}

  @p{««}Transactions with a small number of inputs/outputs, transferring a
  large number of bitcoins, that weren't recently received are the highest
  priority and are included first. @p{»»}

  @p{««}If you send a low-priority transaction without a fee you can end up
  waiting a very long time for it to get confirmed (and it may never be
  confirmed). @p{»»}

  @p{««}Why do miners include free transactions? @p{»»}

  @p{««}Either they're too lazy to change the default rules, or they
  believe that allowing free, high-priority transactions will help make
  Bitcoin more popular and will, therefore, increase the value of their
  coins. @p{»»}

  @p{««}Why is there any incentive to pay fees at all? @p{»»}

  @p{««}You'll notice that pretty much every block nowadays is bigger than
  27k, so there IS competition for that free space. But if you've got 10
  bitcoins that have been sitting in your wallet for a week or three,
  you'll still have no problem spending them without a fee (they'll have a
  much higher priority than somebody playing SatoshiDice 100 times a day).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1965}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-18 17:14:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144895.msg1537055@s{hash}msg1537055
@section 3 {tx}

  @p{««}So... I start from "more transactions == more success" @p{»»}

  @p{««}I strongly feel that we shouldn't aim for Bitcoin topping out as a
  "high power money" system that can process only 7 transactions per
  second. @p{»»}

  @p{««}I agree with Stephen Pair@p{--} THAT would be a highly centralized
  system. @p{»»}

  @p{««}Oh, sure, mining might be decentralized. But who cares if you
  either have to be a gazillionaire to participate directly on the network
  as an ordinary transaction-creating customer, or have to have your
  transactions processed via some centralized, trusted, off-the-chain
  transaction processing service? @p{»»}

  @p{««}So, as I've said before: we're running up against the artificial
  250K block size limit now, I would like to see what happens. There are
  lots of moving pieces here, so I don't think ANYBODY really knows what
  will happen (maybe miners will collectively decide to keep the block
  size low, so they get more fees. Maybe they will max it out to force out
  miners on slow networks. Maybe they will keep it small so their blocks
  relay through slow connections faster (maybe there will be a significant
  fraction of mining power listening for new blocks behind tor, but
  blasting out new blocks not via tor)). @p{»»}

  @p{««} I think we should put users first. What do users want? They want
  low transaction fees and fast confirmations. Lets design for that case,
  because THE USERS are who ultimately give Bitcoin value. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1966}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-18 18:29:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144895.msg1537235@s{hash}msg1537235
@section 3 {tx}

  @p{««}Half-baked thoughts on the O(N) problem: @p{»»}

  @p{««}So, we've got O(T) transactions that have to get verified. @p{»»}

  @p{««}And, right now, we've got O(P) full nodes on the network that
  verify every single transaction. @p{»»}

  @p{««}So, we get N verifications, where N = T*P. @p{»»}

  @p{««}The observation is that if both T and P increase at the same rate,
  that formula is O(N^2). @p{»»}

  @p{««}... and at this point your (and gmaxwell's) imagination seems to
  run out, and you throw up your hands and say "We Must Limit Either T or
  P." @p{»»}

  @p{««}Really? @p{»»}

  @p{««}If we have 20,000 full nodes on the network, do we really need
  every transaction to be verified 20,000 separate times? @p{»»}

  @p{««}I think as T and P increase it'd be OK if full nodes with limited
  CPU power or bandwidth decide to only fetch and validate a random subset
  of transactions. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1967}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-18 19:18:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144895.msg1537333@s{hash}msg1537333
@section 3 {tx}

  @p{««}RE: lots of code to write if you can't keep up with transaction
  volume: sure. So? @p{»»}

  @s{quotedtext}

  @p{««} I really don't understand this logic. @p{»»}

  @p{««}Yes, it is a fact of life that if you have a system where people
  are competing, the people who are less efficient will be driven out of
  business. So there will be fewer people in that business. @p{»»}

  @p{««}You seem to be saying that we should subsidize inefficient miners
  by limiting the block size, therefore driving up fees and making users
  pay for their inefficiency. @p{»»}

  @p{««}All in the name of vague worries about "too much centralization."
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1968}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-19 15:17:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144895.msg1539692@s{hash}msg1539692
@section 3 {tx}

  @p{««}The changes in the last year were "soft forks" @p{--} forks that
  required all miners to upgrade (if they don't, their blocks are
  ignored), but that do not require merchants/users to upgrade. @p{»»}

  @p{««}A couple of random, half-baked thoughts I had this morning: @p{»»}

  @p{««}If you think that the block size should stay at 1 megabyte forever,
  then you're saying the network will never support more than 7
  transactions per second, and each transaction will need to be for a
  fairly large number of bitcoins (otherwise transaction fees will eat up
  the value of the transaction). @p{»»}

  @p{««}If transactions are all pretty big, why the heck do we have 8
  decimal places for the transaction amount? @p{»»}

  @p{««}Don't get me wrong, I still think the bitcoin network is the wrong
  solution for sub-US-penny payments. But I see no reason why it can't
  continue to work well for small-amount (between a US $1 and $0.01)
  payments. @p{»»}

  @p{««}If there are a very limited number of transactions per day and
  billions of dollars worth of BTC being transacted (that's what we all
  want, yes?) then obviously each transaction must be large. So, again,
  why bother having 8 digits after the decimal point if each transaction
  is hundreds of bitcoins big? @p{»»}

  @p{««}Second half-baked thought: @p{»»}

  @p{««}One reasonable concern is that if there is no "block size pressure"
  transaction fees will not be high enough to pay for sufficient mining.
  @p{»»}

  @p{««}Here's an idea: Reject blocks larger than 1 megabyte that do not
  include a total reward (subsidy+fees) of at least 50 BTC per megabyte.
  @p{»»}

  @p{««}"But miners can just include a never broadcast, fee-only
  transactions to jack up the fees in the block!" @p{»»}

  @p{««}Yes... but if their block gets orphaned then they'll lose those
  "fake fees" to another miner. I would guess that the incentive to try to
  push low-bandwidth/CPU miners out of the network would be overwhelmed by
  the disincentive of losing lots of BTC if you got orphaned. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1969}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-19 16:05:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145154.msg1539795@s{hash}msg1539795
@section 3 {tx}

  @p{««}I think casual users should avoid the Satoshi client. Gigabytes of
  blockchain data is not user-friendly, and we've done a lousy job of
  making it hard for users to lose their keys. @p{»»}

  @p{««}I think the something like the blockchain.info web wallet or
  Electrum is a good choice for long-term storage; you keep control over
  your private keys, and are exposed to possible theft risk only when you
  make a transaction (because a hacked blockchain.info could feed you evil
  Javascript, or a hacked Electrum download server could feed you an evil
  executable). The chances that you will be one of the first customers who
  make a transaction after they were hacked, before they took their site
  offline to recover from the hack, are pretty small if you are only
  making a couple of transactions per month. @p{»»}

  @p{««}I'm also assuming that a casual user isn't storing thousands of
  bitcoins. I don't think we have great solutions for casual users with
  thousands of bitcoins yet (I consider paper wallets a fair solution, not
  a great one). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1970}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-19 18:41:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145184.msg1540252@s{hash}msg1540252
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.0 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a major release designed to improve performance and handle
  the @p{brk} increasing volume of transactions on the network. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}The first time you run after the upgrade a re-indexing process will
  be @p{brk} started that will take anywhere from 30 minutes to several
  hours, @p{brk} depending on the speed of your machine. @p{»»}

  @p{««}Incompatible Changes  @p{»»}

  @p{««}This release no longer maintains a full index of historical
  transaction ids @p{brk} by default, so looking up an arbitrary
  transaction using the getrawtransaction @p{brk} RPC call will not work.
  If you need that functionality, you must run once @p{brk} with
  -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
  @p{brk} details). @p{»»}

  @p{««}Improvements  @p{»»}

  @p{««}Mac and Windows binaries are signed with certificates owned by the
  Bitcoin @p{brk} Foundation, to be compatible with the new security
  features in OSX 10.8 and @p{brk} Windows 8. @p{»»}

  @p{««}LevelDB, a fast, open-source, non-relational database from Google,
  is @p{brk} now used to store transaction and block indices. LevelDB
  works much better @p{brk} on machines with slow I/O and is faster in
  general. Berkeley DB is now only @p{brk} used for the wallet.dat file
  (public and private wallet keys and transactions @p{brk} relevant to
  you). @p{»»}

  @p{««}Pieter Wuille implemented many optimizations to the way
  transactions are @p{brk} verified, so a running, synchronized node uses
  less working memory and does @p{brk} much less I/O. He also implemented
  parallel signature checking, so if you @p{brk} have a multi-CPU machine
  all CPUs will be used to verify transactions. @p{»»}

  @p{««}New Features @p{brk} @p{»»}

  @p{««}"Bloom filter" support in the network protocol for sending only
  relevant transactions to @p{brk} lightweight clients. @p{»»}

  @p{««}contrib/verifysfbinaries is a shell-script to verify that the
  binary downloads @p{brk} at sourceforge have not been tampered with. If
  you are able, you can help make @p{brk} everybody's downloads more
  secure by running this occasionally to check PGP @p{brk} signatures
  against download file checksums. @p{»»}

  @p{««}contrib/spendfrom is a python-language command-line utility that
  demonstrates @p{brk} how to use the "raw transactions" JSON-RPC api to
  send coins received from particular @p{brk} addresses (also known as
  "coin control"). @p{»»}

  @p{««}New/changed settings (command-line or bitcoin.conf file) @p{»»}

  @p{««}dbcache : controls LevelDB memory usage. @p{»»}

  @p{««}par : controls how many threads to use to validate transactions.
  Defaults to the number @p{brk} of CPUs on your machine, use -par=1 to
  limit to a single CPU. @p{»»}

  @p{««}txindex : maintains an extra index of old, spent transaction ids so
  they will be found @p{brk} by the getrawtransaction JSON-RPC method.
  @p{»»}

  @p{««}reindex : rebuild block and transaction indices from the downloaded
  block data. @p{»»}

  @p{««}New JSON-RPC API Features @p{»»}

  @p{««}lockunspent / listlockunspent allow locking transaction outputs for
  a period of time so @p{brk} they will not be spent by other processes
  that might be accessing the same wallet. @p{»»}

  @p{««}addnode / getaddednodeinfo methods, to connect to specific peers
  without restarting. @p{»»}

  @p{««}importprivkey now takes an optional boolean parameter (default
  true) to control whether @p{brk} or not to rescan the blockchain for
  transactions after importing a new private key. @p{»»}

  @p{««}Important Bug Fixes@p{»»}

  @p{««}Privacy leak: the position of the "change" output in most
  transactions was not being @p{brk} properly randomized, making network
  analysis of the transaction graph to identify @p{brk} users' wallets
  easier. @p{»»}

  @p{««}Zero-confirmation transaction vulnerability: accepting
  zero-confirmation transactions @p{brk} (transactions that have not yet
  been included in a block) from somebody you do not @p{brk} trust is
  still not recommended, because there will always be ways for attackers
  to @p{brk} double-spend zero-confirmation transactions. However, this
  release includes a bug @p{brk} fix that makes it a little bit more
  difficult for attackers to double-spend a @p{brk} certain type
  ("lockTime in the future") of zero-confirmation transaction. @p{»»}

  @p{««}Dependency Changes @p{»»}

  @p{««}Qt 4.8.3 (compiling against older versions of Qt 4 should continue
  to work) @p{»»}

  @p{««} Thanks to everybody who contributed to this release:@p{»»}

  @p{««}Alexander Kjeldaas @p{brk} Andrey Alekseenko @p{brk} Arnav Singh
  @p{brk} Christian von Roques @p{brk} Eric Lombrozo @p{brk} Forrest
  Voight @p{brk} Gavin Andresen @p{brk} Gregory Maxwell @p{brk} Jeff
  Garzik @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Mike Cassano
  @p{brk} Mike Hearn @p{brk} Peter Todd @p{brk} Philip Kaufmann @p{brk}
  Pieter Wuille @p{brk} Richard Schwab @p{brk} Robert Backhaus @p{brk}
  Rune K. Svendsen @p{brk} Sergio Demian Lerner @p{brk} Wladimir J. van
  der Laan @p{brk} burger2 @p{brk} default @p{brk} fanquake @p{brk}
  grimd34th @p{brk} justmoon @p{brk} redshark1802 @p{brk} tucenaber
  @p{brk} xanatos @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1971}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-19 21:01:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144984.msg1540657@s{hash}msg1540657
@section 3 {tx}

  @p{««}A couple of minor clarifications: @p{»»}

  @p{««}There has always been an artificial block size limit; Satoshi's
  code exponentially increased required transaction fees required to get
  into a block as the block filled up from 250K to an absolute-maximum
  500K. There are almost certainly still miners running with that
  algorithm; their effective maximum block size is a little more than
  250K. @p{»»}

  @p{««}Also, solo/p2p miners and pool operators running a recent version
  of bitcoind can very easily change the maximum block size; it is a
  command-line / bitcoin.conf setting. They don't need to use different
  software.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1972}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 00:13:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144984.msg1541191@s{hash}msg1541191
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, the hard limit has been 1 megabyte forever. But 500K was the
  largest block Satoshi's code could possibly build (I believe that that
  wasn't even possible in practice, because you'd have to spend all 21
  million bitcoins in fees to fill it to 500K). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1973}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 00:24:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144964.msg1541225@s{hash}msg1541225
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... or not. There's a difference between "unfixed vulnerabilities"
  and "half-baked design." @p{»»}

  @p{««}I think big decisions that affect the fundamentals of the design
  should be discussed in the open (see the current Bitcoin debate over
  raising the block size limit). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1974}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 15:37:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145184.msg1542787@s{hash}msg1542787
@section 3 {tx}

  @p{««}A couple people asked if they need to upgrade if they are running
  rc1: no, I wouldn't bother. @p{»»}

  @p{««}The only significant code change is better handling of the rare
  case of one of the leveldb database files being corrupted. If you're
  really curious, github will show you the differences between any two
  versions; here are the rc1 to 0.8.0 final release differences:
  @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1975}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 15:46:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145072.msg1542809@s{hash}msg1542809
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, I believe they would. So far, most miners and pools are VERY
  conservative; I think the idea that they will create huge blocks that
  have a significant risk of being rejected, just so they MIGHT get an
  advantage over marginal miners that can't process them fast enough, is
  loony. @p{»»}

  @p{««}But I might be wrong. @p{»»}

  @p{««}So I'd like to wait a little while, think deeply some more, and see
  how miners and merchants and users react with the system we've got as
  transaction volume increases. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1976}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 19:38:16
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144895.msg1543402@s{hash}msg1543402
@section 3 {tx}

  @p{««}RE: particular ideas if "we" decide the blocksize has to be
  increased: @p{»»}

  @p{««}I think the first step is to come to rough consensus that, at some
  point, we WILL need a hardfork to increase the block size limit. @p{»»}

  @p{««}If we can come to rough consensus on that, then we can figure out
  the safest way to accomplish that. @p{»»}

  @p{««}I don't think we'll get consensus; retep and others will argue "we
  need to run into the hard limit to FORCE alternatives to be created
  first." @p{»»}

  @p{««}I keep saying we should see what happens as we run into the soft
  blocksize limits. To people on both sides of this debate: what do you
  predict will happen? @p{»»}

  @p{««}If what you predict will happen doesn't actually happen, will that
  make you re-evaluate your position? @p{»»}

  @p{««}(I haven't spent enough time thinking about this problem to answer
  those questions, but that is how I'm going to think about it).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1977}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-02-20 22:09:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145498.msg1543844@s{hash}msg1543844
@section 3 {tx}

  @p{««}A hard fork won't happen unless the vast super-majority of miners
  support it. @p{»»}

  @p{««}E.g. from my "how to handle upgrades" gist @s{(link)} @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms1978}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-02 16:05:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=148211.msg1575271@s{hash}msg1575271
@section 3 {tx}

  @p{««}The default block-filling algorithm that most miners are running
  is: @p{»»}

  @p{(li}  Fill up part of the block with the highest transactions,
  regardless of fees  @p{li)}

    @p{(li}@p{(li} Then fill up the rest of the block with as many
    fee-paying transactions as possible, highest fee-per-kilobyte first.
    @p{li)}

  @p{««}... so flooding the network with high-fee transactions won't "stall
  Bitcoin." Well, except for people playing SatoshiDice or doing something
  else that results in lots of low-priority fee-paying transactions (and
  even there, they could always opt to pay a little more in transaction
  fees). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1979}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-04 16:32:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=148211.msg1581733@s{hash}msg1581733
@section 3 {tx}

  @p{««}Yes, I definitely meant priority. Highest priority transactions
  (transferring lots of old coins) get included in blocks first under the
  default block-filling rules. @p{»»}

  @p{««}And also notice that I said "most miners are..." There are at least
  a few big mining pools that have their own idiosyncratic ways of
  deciding which transactions get into blocks, including private deals
  with big exchanges/merchants/etc. @p{»»}

  @p{««}Also note that because finding blocks is a random process the
  Bitcoin network "stalls" for an hour every three weeks or so, with no
  blocks found. @p{»»}

  @p{««}My guess is that if an attacker tried to monopolize block space
  most of us wouldn't even notice. If you're really worried about it, then
  encourage some big mining pool(s) to have a completely different
  block-filling strategy ("randomly select from the memory pool" would be
  easy to implement). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1980}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-05 14:30:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=149164.msg1585838@s{hash}msg1585838
@section 3 {tx}

  @p{««}I wouldn't say NO progress is being made, but there has been a long
  detour because we need a secure way of telling you WHO you are paying to
  make multisignature work securely. Otherwise we could have the most
  nifty, secure multisig system in the world that fails because you THINK
  you're paying 1kqHKEYYC8CQPxyV53nCju4Lk2ufpQqA2 but a crafty attacker
  makes you pay them at 1kqHLFyZDBDoPDYwSEtjv5CWka42uGqA2 instead. @p{»»}

  @p{««}So I've been spending most of my time implementing "the payment
  protocol." I'll write more in a Foundation blog post on Friday. @p{»»}

  @p{««}Payment protocol messages will be part of the information that will
  be sent between devices or people to make multisig transactions work.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1981}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-07 17:10:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=149668.msg1596692@s{hash}msg1596692
@section 3 {tx}

  @p{««}You may have heard me say "Bitcoin is an experiment" before...
  well, we're finding out right now what happens as the experiment scales
  up. @p{»»}

  @p{««}First: I sent a message to the big mining pools, reminding them of
  the run-time options they can set to control the size of the blocks they
  create. I did not tell them what they should or shouldn't do, I think we
  need to move beyond centralized decision-making. @p{»»}

  @p{««}I did send them a pointer to this very rough back-of-the-envelope
  estimate on the current marginal cost of transactions: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}(if anybody wants to do a better analysis, I'd love to read it).
  @p{»»}

  @p{««}Second: block size is half of the equation. The other half is
  transaction fees and competition for getting included into blocks. All
  of the bitcoin clients need to do a better job of figuring out the
  'right' transaction fee, and services that generate transactions will
  have to adjust the fees they pay (and are, already). @p{»»}

  @p{««}Finally: in my opinion, there is rough consensus that the 1MB block
  size limit WILL be raised. It is just a question of when and how much /
  how quickly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1982}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-08 20:44:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=150686.msg1601467@s{hash}msg1601467
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms1983}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-10 03:10:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151329.msg1606071@s{hash}msg1606071
@section 3 {tx}

  @s{quotedtext}

  @p{««} How much does it cost, if you assume reasonable trends for
  storage/electricity cost? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1984}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-10 17:29:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151329.msg1607938@s{hash}msg1607938
@section 3 {tx}

  @s{quotedtext}

  @p{««}I agree. @p{»»}

  @p{««}That is why I ask "what is the external cost, with reasonable
  assumptions." @p{»»}

  @p{««}So I'll ask again: what is the
  cost-per-(pick-your-favorite-time-unit) to the network of an extra
  unspent transaction output? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1985}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-10 17:55:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151329.msg1608008@s{hash}msg1608008
@section 3 {tx}

  @p{««}Why did you pick 0.0005 BTC ? That is a mostly arbitrary number.
  @p{»»}

  @p{««}I estimate a current-worst-case "orphan cost" of an average
  250-byte transaction is 0.00008 BTC. See @s{(link)} (more accurate
  analyses welcome, I don't pretend to have a monopoly on the "right"
  answer). @p{»»}

  @p{««}That number will drop as CPUs get faster/cheaper, or bitcoin value
  rises. So you could argue that even though dust is not economical to
  spend today, in 20 years it will be. @p{»»}

  @p{««}So I guess I'll rephrase my question again: Rough,
  back-of-the-envelope: how much does it cost to keep a dust-like
  transaction output in the unspent outputs set for 20 years? @p{»»}

  @p{««}If it is a lot, then we should set the "expected time when it will
  be economical to spend" to either "right now" or "very soon." @p{»»}

  @p{««}If it is tiny, then we shouldn't worry so much about optimizing
  unspent txout size, and concentrate on other things. @p{»»}

  @p{««}I have no idea what the answer is. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1986}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-10 19:16:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151329.msg1608267@s{hash}msg1608267
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sigh. @p{»»}

  @p{««}Ok, fine, so do a back-of-the-envelope for what THAT cost is. @p{»»}

  @p{««}Big +1 to d'aniel for doing the work of actually calculating a
  number, that is very helpful.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1987}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-10 19:34:12
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151348.msg1608325@s{hash}msg1608325
@section 3 {tx}

  @p{««}It is a problem if you send a transaction from one of the copies of
  the wallet while it is catching up with the blockchain. You can easily
  accidentally double-spend yourself, and end up with a transaction that
  will never confirm. @p{»»}

  @p{««}Deterministic wallets don't solve that problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1988}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-11 13:14:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151657.msg1610859@s{hash}msg1610859
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think this is exactly right. @p{»»}

  @p{««}But I also think that choosing a larger-but-still-limited block
  size won't kill Bitcoin (but not raising the block size at all
  might@p{--} a payment system with a hard seven-transactions-per-second
  limit is not Satoshi's vision).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1989}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-11 16:04:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151657.msg1611373@s{hash}msg1611373
@section 3 {tx}

  @s{quotedtext}

  @p{««}I think you don't understand how mining works@p{--} there is no
  such thing as a "faster" miner, just miners with more or less chance of
  creating the next block. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1990}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-14 03:25:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140233.msg1622575@s{hash}msg1622575
@section 3 {tx}

  @s{quotedtext}

  @p{««}Ah, excellent, can you please send me the documentation that says
  exactly how many locks will be taken by each bdb operation? I haven't
  been able to find that. Thanks! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1991}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-14 03:47:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=140233.msg1622637@s{hash}msg1622637
@section 3 {tx}

  @p{««}If Mr. Augustus found some documentation that I don't know about
  it, I genuinely want to know about it, because it will save me time.
  Right now I'm throwing blocks at an instrumented v0.7.2 bitcoind that
  tells me how many locks are taken, so I can be sure whatever fix we
  implement will always work. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1992}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-14 23:20:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=153170.msg1625891@s{hash}msg1625891
@section 3 {tx}

  @p{««}The first part of the chain that got orphaned, starting at block
  225,430, is here: @p{»»}

  @p{««} @s{(link)} @p{»»}

  @p{««}The first three blocks in the 0.7-compatible chain starting at
  block 225,430 is: @p{»»}

  @p{««} @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1993}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-16 19:55:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=152290.msg1631784@s{hash}msg1631784
@section 3 {tx}

  @s{quotedtext}

  @p{««}No, that is not true. @p{»»}

  @p{««}The only condition of my visit to the CIA was that I not use the
  fact that I visited there in any type of advertising. @p{»»}

  @p{««}Well, that and to abide by their normal security while I was there:
  no cell phone or other electronic devices allowed, no trying to wander
  off by myself unescorted. @p{»»}

  @p{««}I am completely free to talk about what happened, and if you buy me
  a beer sometime I'd be happy to answer any questions you have. Just not
  here, too many trolls and I've already spent too much time before and
  after the trip trying (and failing) to keep the conspiracy theories in
  check.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1994}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-16 20:44:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=153974.msg1631931@s{hash}msg1631931
@section 3 {tx}

  @p{««}Please stop the "Gavin's decision" meme, too: I went with the
  in-the-moment consensus when it became clear that it was POSSIBLE to
  switch to the 0.7 fork. @p{»»}

  @p{««}And as Melbustus said: that was only possible because the split was
  close to 50/50. If more miners had already upgraded to 0.8, an alert
  would have been sent to non-0.8 peers telling them to either upgrade or
  shutdown until we could find a workaround for the problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1995}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-17 18:49:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=153974.msg1634866@s{hash}msg1634866
@section 3 {tx}

  @s{quotedtext}

  @p{««} More documentation is great, so yeah, if you want a formal spec,
  go for it. @p{»»}

  @p{««}Here's a tricky question you can start with: @p{»»}

  @p{««}Assume there is a fork consisting of max-block-size blocks. How
  deep a fork/re-organization MUST a conforming implementation handle? 6
  blocks? 1000 blocks? as-many-blocks-as-there-are-in-the-chain blocks?
  @p{»»}

  @p{««}Does that imply that a confirming implementation MUST be running
  with a certain amount of memory, or MUST a conforming implementation be
  able to handle such a chain fork within a certain amount of time? @p{»»}

  @p{««}.. and once you answer all that: what if the network consists
  entirely of non-conforming implementations that take shortcuts and just
  assume that there will never be a re-org more than X blocks deep?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1996}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-18 15:35:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154516.msg1637665@s{hash}msg1637665
@section 3 {tx}

  @p{««}Bitcoin-Qt/bitcoind version 0.8.1 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release that adds a new network rule to avoid
  @p{brk} a chain-forking incompatibility with versions 0.7.2 and earlier.
  @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.1 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1997}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-18 15:52:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154521.msg1637728@s{hash}msg1637728
@section 3 {tx}

  @p{««}Last July, @p{(link}BIP 34@p{link)} was accepted. It specifies a
  "soft fork": @p{»»}

  @s{quotedtext}

  @p{««} We are getting close to that threshold: 821 out of the latest 1000
  blocks were version 2. @p{»»}

  @p{««}If you are mining in a pool: there is a list of pools and what
  versions they are producing @p{(link}here.@p{link)} If your pool is
  producting version=1 blocks, you should urge your pool operator to
  upgrade or patch. @p{»»}

  @p{««}If you are mining with p2pool or solo and using a very old version
  of bitcoind: you should upgrade, or you risk your blocks getting
  orphaned. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1998}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-18 15:59:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154516.msg1637762@s{hash}msg1637762
@section 3 {tx}

  @s{quotedtext}

  @p{««}No; the only 0.8 users who should upgrade are miners who are
  creating blocks themselves (mining pool operators, solo miners, or
  people using p2pool). @p{»»}

  @p{««}Big merchants/services/exchanges who want to be as certain as
  possible they don't end up on the wrong side of a blockchain fork should
  also upgrade, although I think the risk of that happening if they keep
  running 0.8.0 is small. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms1999}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-18 16:18:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144331.msg1637851@s{hash}msg1637851
@section 3 {tx}

  @p{««}The bottleneck for getting this pulled is testing. @p{»»}

  @p{««}It needs a thorough test plan that tries to test edge cases where
  things might break, and then it needs people to carry out that test plan
  to make sure it is solid. "It works for me" isn't good enough for
  wallet-touching code. @p{»»}

  @p{««}See @s{(link)} for a suggested process. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2000}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-20 12:37:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154521.msg1646930@s{hash}msg1646930
@section 3 {tx}

  @p{««}There are three stages to the rollout: @p{»»}

    @p{(li} 1. Before 75% are producing block.version=2 blocks: no special
  checking @p{brk} 2. Between 75 and 95% : block.version=2 blocks MUST
  have height in coinbase. We are here. @p{brk} 3. 95% or more: all blocks
  MUST be block.version=2 and MUST have height in coinbase. Should happen
  soon. @p{li)}

  @p{««}Shell script to count block versions: @p{»»}

   @s{code}

# ----------------------------------------------------------------------
@section 2 {ms2001}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-20 20:17:11 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=155497.msg1649038@s{hash}msg1649038
@section 3 {tx}

  @p{««}Suggestion: instead of talking endlessly about possible attacks,
  try them out on the -testnet test network. @p{»»}

  @p{««}That is what it is for. @p{»»}

  @p{««}Oh: except Sybil attacks, which just aren't very interesting on a
  network like testnet that has only a couple dozen peers on it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2002}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-22 01:55:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=57027.msg1656014@s{hash}msg1656014
@section 3 {tx}

  @p{««}I just used some bitcoins from the Bitcoin Faucet fund to
  compensate the p2pool miners who's block was orphaned in the Big Chain
  Fork. @p{»»}

  @p{««}Transaction id
  6521b0513f3077a983b82eb92cc95ecc24ad2a7ca3afdba082ef71ea8d25a868 @p{»»}

  @p{««}PS: this was a one-time thing, don't expect orphan blockss in the
  future to get paid for! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2003}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-22 20:16:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154672.msg1659996@s{hash}msg1659996
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you're exactly right. @p{»»}

  @p{««}FinCEN cares mostly about big-time money laundering and terrorist
  financing. If I was running a cash-for-bitcoins service in the US and
  started moving more than a few hundred bitcoins a month through my bank
  account, then I'd talk to a lawyer. If I was running an exchange, I
  would have already talked to a lawyer. If I was a US-based miner
  exchanging more than a few hundred freshly-made bitcoins for cash every
  month, then I would talk with a lawyer. If you hold other people's
  bitcoins... then I'd talk with a lawyer (even if you're not a money
  transmitter, there might be consumer protection or banking laws that
  might apply). @p{»»}

  @p{««}Otherwise, I wouldn't worry. If I was a miner transferring my
  bitcoins to an exchange and selling them, then FinCEN won't come after
  me. FinCEN will get reports from the exchange, and that's what they
  really care about. The IRS might come after me if I don't report the
  income, but I think they'd charge me with tax evasion, not being an
  unlicensed money transmitter. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2004}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-22 22:47:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=156641.msg1660732@s{hash}msg1660732
@section 3 {tx}

  @p{««}After talking with a few groups of people, I decided a good use of
  Bitcoin Faucet funds would be compensating miners who had blocks that
  were orphaned in last week's Bit Chain Fork. @p{»»}

  @p{««}This is a one-time thing@p{--} don't expect orphaned blocks in the
  future to be compensated! It is just a coincidence that I haven't had
  time to fix the Faucet, and have a bunch of coins waiting to be given
  away. @p{»»}

  @p{««}Transaction id paying the to the addresses in the coinbases of the
  orphaned blocks:
  c931f1aa9f0d211dca085342ec472e77b538b55980a2c7b0ff9fab9a20a9acd2 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2005}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-23 13:37:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=156816.msg1663171@s{hash}msg1663171
@section 3 {tx}

  @p{««}Somebody should exploit all the DoS bugs that have been fixed to
  put the dead altcoins out of their misery, starting with the BDB lock
  limit bug. @p{»»}

  @p{««}Because if they keep scraping along, the worst thing that could
  happen would be for them to suddenly get popular@p{--} because then
  attackers WILL swoop in and cause chaos.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2006}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-23 13:50:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=156641.msg1663216@s{hash}msg1663216
@section 3 {tx}

  @p{««}To be clear: the 'donor' was the EFF, and their only request was
  that the Bitcoins be given back to the bitcoin community. If you like,
  think of it as a bulk payment of transaction fees that the faucet would
  have paid if it had been operating over the last year instead of closed
  (due to lack of time for me to fight the scammers). @p{»»}

  @p{««}Because it sent tiny transaction amounts, it paid almost as much in
  fees as it gave out...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2007}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-23 22:20:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=154516.msg1665186@s{hash}msg1665186
@section 3 {tx}

  @p{««}If you're on Linux or Mac, run contrib/tidy_datadir.sh if you want
  to get rid of old, not-used-any-more files in your data directory. @p{»»}

  @p{««}It will safely remove the blkindex.dat and blk000?.dat files. @p{»»}

  @p{««}If somebody wants to write an equivalent .bat file that does the
  same on Windows, that'd be fantastic! I don't know hardly nuthin about
  Windows batch files. @p{»»}

  @p{««}As deepceleron says, the blk000?.dat files are hardlinks, so even
  though it looks like they're taking up space they're not. And they're
  safe to delete (just don't delete anything in the blocks/ or chainstate/
  folders). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2008}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-23 22:31:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=156334.msg1665231@s{hash}msg1665231
@section 3 {tx}

  @p{««}Straight Bitcoin isn't designed for really small transactions. If
  you're sending less than something like $1 worth of bitcoins, you should
  expect to pay 10% or more in fees. More if you're trying to send $0.10
  or less. @p{»»}

  @p{««}There is no magic fairy wand we can wave and make Bitcoin suddenly
  great for gazillions of tiny transactions; plan your businesses
  accordingly. As transaction volume increases, there will be more
  competition for space in blocks and fees are likely to rise. @p{»»}

  @p{««}And please avoid filling your customer's wallets with "dust" that
  they'll pay huge fees to spend; a payout should be at least a couple of
  cents, not a fraction of a penny. I think there is pretty good consensus
  among the core developers that sooner or later we'll make "dust" outputs
  non-standard, so they are not relayed or mined by default (details to be
  worked out, we need to implement a good algorithm for auto-adjusting the
  definition of "dust"). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2009}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-27 20:14:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=159238.msg1688586@s{hash}msg1688586
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ummm.... speaking of the hardfork, has a version of Litecoin been
  released yet that fixes the problem? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2010}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-28 12:56:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=148712.msg1692471@s{hash}msg1692471
@section 3 {tx}

  @p{««}Bitcoin is not a single product any more, so a "Download Now!"
  button doesn't make sense any more. @p{»»}

  @p{««}Just like bittorrent or linux aren't single products. And if you
  visit bittorrent.org or linux.org... guess what? No download button.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2011}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-28 16:46:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=159238.msg1693700@s{hash}msg1693700
@section 3 {tx}

  @s{quotedtext}

  @p{««} Not rhetorical: it needs to be fixed, or your blockchain can
  easily be forked. @p{»»}

  @p{««}Beware of Altchains that are abandoned or neglected by their
  developers (activity at @s{(link)} doesn't look healthy to me... and now
  y'all are going to accuse me of spreading FUD, so I'll go away and shut
  up). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2012}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-29 15:12:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160785.msg1699835@s{hash}msg1699835
@section 3 {tx}

  @p{««}So.... move too fast and we maybe introduce a forking bug or a
  security vulnerability. @p{»»}

  @p{««}Move too slow and maybe we get fired@p{--} somebody faster at
  incorporating safe changes releases their own fork. @p{»»}

  @p{««}For me, "move slow" is the right answer. @p{»»}

  @p{««}But I would be completely happy contributing patches to somebody
  else running a fork who solves the "move fast but be safe" problem.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2013}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-29 16:22:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160692.msg1700155@s{hash}msg1700155
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure. @p{»»}

  @p{««}First, you need to make sure miners will accept bitcoins with the
  lower fee. So lobby your favorite miner or mining pool to set the
  -mintxfee= parameter to something lower than the default 0.0005
  BTC-per-kilobyte; you can ask them if they will increase the size of the
  blocks they're creating and include more free transactions, too (those
  are settings they control). @p{»»}

  @p{««}Then, if you're using Bitcoin-Qt, you can set the transaction fee
  in the Preferences/Options dialog. @p{»»}

  @p{««}Right now, network peers won't relay low-priority transactions that
  include a fee of less than 0.0001 BTC, so that is as low as you should
  go. Fixing that is near the top of the (long) TODO list, but I really
  want to fix it correctly so we developers get out of the business of
  deciding what the transaction fees should be, and instead let the
  network decide. @p{»»}

  @p{««}If you generate a small number of high-bitcoin-value transactions
  (e.g. you have more than 1 BTC in your wallet and make a few purchases a
  week) then you should probably leave the Pay transaction fee setting at
  zero; Bitcoin-Qt will send your transactions without a fee, which will
  be just fine. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2014}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-29 16:28:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160821.msg1700174@s{hash}msg1700174
@section 3 {tx}

  @s{quotedtext}

  @p{««} Transactions larger than 100K are non-standard now, so I doubt the
  big transaction was ever broadcast. Almost certainly the transaction
  belonged to the miner, and they paid the fees to themself. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2015}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-29 19:24:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160785.msg1701067@s{hash}msg1701067
@section 3 {tx}

  @s{quotedtext}

  @p{««} So... you complain about development not happening faster, and
  then you complain that I'm not spending all of my time here on the
  forums? @p{»»}

  @p{««}"okey dokey" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2016}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-30 12:59:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=158469.msg1704568@s{hash}msg1704568
@section 3 {tx}

  @p{««}Wiki is out of date. Everybody running their node as a tor hidden
  service would work just fine as of a couple of releases ago.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2017}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-31 01:14:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=162336.msg1707686@s{hash}msg1707686
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nice! We need a good Mac OSX developer, do you know C++? Are you
  willing to learn Qt? @p{»»}

  @p{««}My main machine is a Mac, but I'm not an expert OSX developer (I
  spend all my time in a Terminal window in emacs, pretending my Mac is a
  Unix machine). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2018}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-31 22:17:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160785.msg1711596@s{hash}msg1711596
@section 3 {tx}

  @p{««}r.willis is confused about the BIP process. @p{»»}

  @p{««}It is not "Write a specification. Submit a BIP. Argue for a while,
  revise the specification. Finalize BIP, then everybody agrees to
  implement it." @p{»»}

  @p{««}I know there are standardization processes that try to work that
  way, and they're generally miserable failures. You end up with bloated
  specifications and implementations that don't work with each other
  because everybody interprets the spec slightly differently. @p{»»}

  @p{««}I like the IETF model, of working code and rough consensus. So,
  once the payment protocol is implemented and early adopters have had a
  chance to play with it, it will become a formal BIP. Until then, as Mike
  said, I'll be tweaking @s{(link)} as I run into issues.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2019}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-03-31 23:23:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=162522.msg1711886@s{hash}msg1711886
@section 3 {tx}

  @p{««}The only security risk with free bitcoin services is that they'll
  remember your IP address and associate it with the millibitcoins that
  they give you. @p{»»}

  @p{««}If you're the conspiracy theory type, then here's one for you: a
  very good way for a Three Letter Agency to create a database that
  correlates bitcoin wallets to real people would be for them to run a
  free bitcoin service (along with whatever they're currently doing to
  correlate IP addresses with real people). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2020}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-02 14:58:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160306.msg1722532@s{hash}msg1722532
@section 3 {tx}

  @p{««}Here's the thumbnail sketch on the code that I think needs to be
  written to handle fees properly: @p{»»}

  @p{««}1). Memory-limit the memory pool@p{--} the set of transactions
  waiting in memory eligible to be included in a block. Matt Corallo has
  been working on that. The limit should be a small multiple of the median
  block size of the last few hundred blocks. @p{»»}

  @p{««}2) Use the same algorithm/parameters/etc for adding transactions to
  the memory pool that we use to fill blocks. @p{»»}

  @p{««}3) Only relay transactions that fit into your memory pool. This is
  the DoS prevention, your transaction won't get relayed if your node
  doesn't think it will end up in a block soon. @p{»»}

  @p{««}4) Estimate minimum transaction fee / priority needed to get into a
  block, based one: @p{»»}

    @p{(li} a) At startup: the transactions in the last few blocks @p{li)}

    @p{(li} b) If you've been running long enough to "warm up" your memory
    pool: transactions in the memory pool @p{li)}

  @p{««}5) Expose the estimate in the GUI's "suggested transaction fee"
  dialog. @p{»»}

  @p{««}All of that will give a floating fee that will change based on how
  many transactions, at what priorities/fees, are currently waiting to get
  into blocks. @p{»»}

  @p{««}There is one more change I'd like to make that is independent;
  re-define "dust" based on the floating transaction fee (e.g. a dust
  output is any output with a value of less than 1/4 the minimum
  fee-per-kb required to get into one of the next 6 blocks). And make any
  transactions with dust outputs non-standard, so they're not included in
  the memory pool or relayed.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2021}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-02 17:13:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=160306.msg1723484@s{hash}msg1723484
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because dust outputs are more trouble than they're worth. They
  bloat wallets, cost more in fees to spend than they're worth (unless you
  go to ridiculous lengths to spend them), and are abused as a
  side-channel-in-the-blockchain-communication-mechanism. @p{»»}

  @p{««}If I could go back in time, I would go back and try to convince
  Satoshi to make them non-standard to begin with....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2022}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-05 02:47:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=167646.msg1745634@s{hash}msg1745634
@section 3 {tx}

  @s{quotedtext}

  @p{««} You're assuming that miners are completely distinct from the
  people who want the network to be secure
  (users/merchants/exchanges/etc). @p{»»}

  @p{««}That is a bad assumption. Nothing stops a merchant who wants more
  network security from either subsidizing miners (maybe in exchange for a
  promise to prioritize transactions to them) or mining themselves. @p{»»}

  @p{««}This is already happening, not for reasons of security but for
  other reasons. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2023}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-05 20:50:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=166302.msg1751772@s{hash}msg1751772
@section 3 {tx}

  @p{««}I think there doesn't have to be One True Answer, and I'd like to
  see the different clients experiment with different ways of estimating
  fees. @p{»»}

  @p{««}I like your idea, Jan@p{--} go for it! @p{»»}

  @p{««}I want Consumer Reports magazine to do an article in 15 years
  comparing bitcoin wallets and figuring out which one gives the fastest
  transactions for the lowest fees... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2024}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-06 18:49:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=157141.msg1758131@s{hash}msg1758131
@section 3 {tx}

  @p{««}So the longer I think about the block size issue, the more I'm
  reminded of this Hayek quote: @p{»»}

  @s{quotedtext}

  @p{««} We can speculate all we want about what is going to happen in the
  future, but we don't really know. @p{»»}

  @p{««}So, what should we do if we don't know? My default answer is "do
  the simplest thing that could possibly work, but make sure there is a
  Plan B just in case it doesn't work." @p{»»}

  @p{««}In the case of the block size debate, what is the simplest thing
  that just might possibly work? @p{»»}

  @p{««}That's easy! Eliminate the block size limit as a network rule
  entirely, and trust that miners and merchants and users will reject
  blocks that are "obviously too big." Where what is "obviously too big"
  will change over time as technology changes. @p{»»}

  @p{««}What is Plan B if just trusting miners/merchants/users to do the
  right thing doesn't work? @p{»»}

  @p{««}Big-picture it is easy: Schedule a soft-fork that imposes some
  network-rule-upper-limit, with whatever formula seems right to correct
  whatever problem crops up. @p{brk} Small-picture: hard to see what the
  "right" formula would be, but I think it will be much easier to define
  after we run into some actual practical problem rather than guessing
  where problems might crop up. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2025}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-06 18:57:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=168864.msg1758171@s{hash}msg1758171
@section 3 {tx}

  @s{quotedtext}

  @p{««} Exactly. @p{»»}

  @p{««}DO NOT SELL TESTNET COINS. You'll just piss off the core
  developers, because we'll have to waste time re-launching a new testnet
  to reset the chain and make the coins worthless again. @p{»»}

  @p{««}There a Fight Club "First Rule..." joke in there somewhere....
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2026}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-06 20:41:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=157141.msg1758794@s{hash}msg1758794
@section 3 {tx}

  @s{quotedtext}

  @p{««} Okey dokey. @p{»»}

  @p{««}If you want to be helpful, please write up a list of pros and cons
  for the various plans that have been proposed, including your own (last
  time I asked you, you waffled and didn't have any plan). @p{»»}

  @p{««}I've been pretty busy dealing with the avalanche of press and
  working on the payment protocol.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2027}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-07 17:28:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=169681.msg1764550@s{hash}msg1764550
@section 3 {tx}

  @p{««}I think the big difference between the "bitcoin elites" and the
  existing financial system elites is the "bitcoin elites" are working
  really hard to distribute our power. @p{»»}

  @p{««}We're getting there, but it will take time. I really hope in a year
  or two there will be at least three or four different bitcoin
  implementations all producing blocks, validating transactions, etc. And
  in ten years there will be a dozen or more. @p{»»}

  @p{««}That is a natural progression; I was around when NCSA Mosaic was
  the one web browser and the NCSA server was the only web server, and
  there have been a couple cycles of certain browsers / web servers
  becoming dominant and then fading. I expect to see a similar evolution
  for Bitcoin infrastructure software. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2028}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-10 16:29:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=157141.msg1794856@s{hash}msg1794856
@section 3 {tx}

  @s{quotedtext}

  @p{««}Nah, I now think that's a dumb idea. @p{»»}

  @p{««}Responding to gmaxwell: @p{»»}

  @p{««}RE: burden of unpaid full nodes: for the immediately forseeable
  future, that burden is on the order of several hundred dollars a year to
  buy a moderately beefy VPS somewhere. @p{»»}

  @p{««}I understand the "lets engineer for the far future" ... but,
  frankly, I think too much of that is dumb. Successful projects and
  products engineer for the next year or two, and re-engineer when they
  run into issues. @p{»»}

  @p{««}Maybe the answer will be "validation pools" like we have mining
  pools today, where people cooperate to validate part of the chain (bloom
  filters, DHTs, mumble mumble....). Maybe hardware will just keep up.
  @p{»»}

  @p{««}RE: race to the bottom on fees and PoW: @p{»»}

  @p{««}sigh. Mike explained how that is likely to be avoided. I'm 100%
  convinced that if users of the network want secure transactions they
  will find a way to pay for them, whether that is assurance contracts or
  becoming miners themselves. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2029}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-12 20:03:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=175026.msg1821877@s{hash}msg1821877
@section 3 {tx}

  @p{««}For the record: @p{»»}

  @p{««}I think testing a gazillion pulls at once is madness, because if
  something doesn't work it can be incredibly difficult to figure out
  which of the gazillion changes made it break. Assuming that just once
  change made it break and not some subtle interaction between two or
  three or six changes... @p{»»}

  @p{««}If you want to help test, I think it would be much more helpful if
  you find a feature you care about, grab the binaries that the
  pull-tester creates, test thoroughly, and then report results in the
  pull request on github. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2030}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-13 21:23:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=175871.msg1832089@s{hash}msg1832089
@section 3 {tx}

  @p{««}I think including a message that is NOT stored in the blockchain
  but is just broadcast across the network is a good idea. The receiver
  would only get the message if they were online and saw the transaction
  broadcast, but I think that would be fine (and perhaps services would
  spring up to deliver the extra transaction data associated with old
  transactions). @p{»»}

  @p{««}First, though, I think the transaction memory pool needs to be
  re-implemented, and the transaction relaying rules need to be changed so
  that the entire size of the transaction (not just the part that will be
  stored in the block chain) is considered in the priority/fee
  calculations. @p{»»}

  @p{««}And fixing the client so it calculates fees properly is higher
  priority... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2031}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-18 16:17:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1319.msg1875749@s{hash}msg1875749
@section 3 {tx}

  @p{««}See -blocknotify and -walletnotify command-line options in the
  latest code, which will run an arbitrary command when new blocks happen
  or transactions hit your wallet (and that arbitrary command can be "POST
  information to this URL..."). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2032}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-19 13:29:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=180020.msg1885226@s{hash}msg1885226
@section 3 {tx}

  @p{««}Howdy Adam! @p{»»}

  @p{««}I'm going to quote myself, this is from an email I wrote yesterday
  to somebody else concerned about chip/mining centralization: @p{»»}

  @s{quotedtext}

  @p{««} In the very long run, mining will be dominated by your cost of
  electricity and your ability to put the excess heat generated to good
  use. @p{»»}

  @p{««}I don't think it will matter what algorithm is used or even if the
  algorithm was changed every six months; if a general-purpose CPU was the
  only thing you could use for mining, you might see general-purpose CPUs
  designed to operate at thousands of degrees celsius being designed so
  that aluminum smelting plants can also mine bitcoins with all that
  electricity they use turning bauxite into aluminum. @p{»»}

  @p{««}In the short run... I think there is zero chance that "we" will
  decide to change the hashing algorithm. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2033}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-20 20:10:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=181168.msg1897036@s{hash}msg1897036
@section 3 {tx}

  @p{««}I think a diversity of views is good, as long as the people
  expressing their views are honest, trustworthy, and respectable. @p{»»}

  @p{««}I still think Luke causes more trouble and strife than he is worth.
  And I wish people would stop implying he is part of the core development
  team.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2034}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-22 19:17:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=182992.msg1913758@s{hash}msg1913758
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, unless you take complete control over input selection and
  transaction creation using the raw transactions API. @p{»»}

  @p{««}If you have multiple users sharing the same wallet, then reasonable
  ways of handling transaction fees are: @p{»»}

  @p{««}Keep track of who owns which inputs and use the raw transactions
  API to charge users fees based on what the inputs look like. @p{»»}

  @p{««}Just pay transaction fees for your users. If you work out how much
  that will cost you versus how much time you'll spend with a more
  complicated solution, you'll probably find this is the best solution. If
  you're using the 'accounts' feature, then the logic is: Send the
  transaction, then get the transaction details and reimburse the
  transaction fee (if any) with a 'move' that transfers bitcoins from a
  transaction-fee-reimbursement account (which you finance in advance, and
  top-up when necessary) to the user's account. @p{»»}

  @p{««}Or charge them a fixed fee that is enough to cover average costs
  (again, if using accounts you'd move bitcoins to/from the transaction
  fee account depending on whether a given transaction cost more or less
  than average). @p{»»}

  @p{««}Otherwise, you'll have a situation where user A gets gazillions of
  tiny inputs credited to their account, and user B ends up paying to
  spend them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2035}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-23 00:59:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=181168.msg1916410@s{hash}msg1916410
@section 3 {tx}

  @s{quotedtext}

  @p{««} Mmm. And I'm working hard to try to delegate that authority, so
  can y'all please just work it out? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2036}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-25 16:58:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=187595.msg1942417@s{hash}msg1942417
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2037}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-25 17:00:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=187595.msg1942435@s{hash}msg1942435
@section 3 {tx}

  @p{««}Thought it might be interesting for y'all to see the 'raw
  interview': @p{»»}

  @s{quotedtext}

  @p{««}Bitcoin is an open, international payment network. More and more
  businesses are choosing to accept bitcoins because it is an easy way to
  allow anybody, anywhere in the world, to pay for products or
  services@p{--} even people from countries where credit cards and bank
  accounts might not be common. @p{»»}

  @p{««}It is also very low-cost, because it was designed for the Internet.
  @p{»»}

  @p{««}Individuals use it for a few different reasons. @p{»»}

  @p{««}The earliest adopters started using bitcoins either because they
  like the idea (for political or personal reasons) of using a currency
  that isn't controlled by a government or corporation or just because it
  was "new and cool." @p{»»}

  @p{««}Some people use it because they have no other choice; for example,
  more and more legal, online gaming sites use bitcoins to make it
  possible for players in countries that try to restrict onling gaming
  (like the US) to play. @p{»»}

  @p{««}We're just starting to see individuals using bitcoin because it
  saves them money; merchants are starting to pass on some of the savings
  (much lower transaction fees, no "chargebacks") to customers who pay
  using bitcoin. @p{»»}

  @s{quotedtext}

  @p{««}People trust that it isn't going to disappear, because there is no
  central organization that can either go bankrupt or be forced to shut
  down by a government. Currencies are all about trust, and more people
  are beginning to trust this decentralized currency that is supported by
  everybody who uses it. @p{»»}

  @p{««} @p{»»}

  @s{quotedtext}

  @p{««}I still tell people "only invest time or money into Bitcoin that
  you can afford to lose." I expect more drama and chaos and price
  fluctuations in the short-term. The current price bubble was driven by
  lots of attention in the press here in the US and in Europe, and all of
  the attention was self-reinforcing: stories about Bitcoin's dramatic
  price rise got people interested, which drove the price higher, which
  triggered even more stories. @p{»»}

  @p{««}I expect that will happen again in the next few years, perhaps in a
  different area of the world (maybe there will be a China-driven bitcoin
  bubble in a few years that will pop when the Chinese government decides
  to try to restrict bitcoin transaction across their Great Firewall).
  @p{»»}

  @p{««}But in the long-term, I expect that to settle down, and the value
  of a bitcoin to become much more stable. @p{»»}

  @s{quotedtext}

  @p{««}Actually, the valuation isn't a big barrier to adoption. There are
  already services that help companies manage the currency exchange risk
  (you can peg your prices to dollars, your customers can pay the
  equivalent amount in bitcoins, and you get dollars deposited to your
  bank account), and as the financial service infrastructure for Bitcoin
  get more mature that will just get easier. @p{»»}

  @p{««}Any important new technology grows by starting with successes in
  some niches where its advantages are overwhelming; ubiquitous
  technologies then manage to slowly grow out of those niches to take over
  markets where they have a marginal advantage (either in convenience or
  price). @p{»»}

  @p{««}That is the pattern we're already seeing with Bitcoin, starting
  with niches where the advantages are too large to ignore (e.g. online
  gaming, international payments). It remains to be seen whether or not
  Bitcoin can grow out of those niches to become a ubiquitous form of
  payment. In theory, the value of a currency increases as more people use
  it. Since the potential market for Bitcoin is every person connected to
  the Internet, it could become more valuable than any national currency
  that is tied to one specific geographic region of the planet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2038}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-26 17:06:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=188460.msg1952858@s{hash}msg1952858
@section 3 {tx}

  @p{««}Probably more effective to ask if you can contribute to their
  campaign using Bitcoin. @p{»»}

  @p{««}They like getting money. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2039}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 01:11:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=188695.msg1956034@s{hash}msg1956034
@section 3 {tx}

  @p{««}Meh. @p{»»}

  @p{««}Lots of other ways that merchants could arrange to pay transaction
  fees, I don't think we need a hard fork to solve that problem. @p{»»}

  @p{««}E.g. : child-pays-for-parent. @p{»»}

  @p{««}Or an extension to the payment protocol so the merchant provides an
  already-signed SIGHASH_SINGLE / SIGHASH_ANYONECANPAY input to pay the
  fee that the client includes as the first input in the transaction.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2040}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 18:36:56
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=177679.msg1960921@s{hash}msg1960921
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh. What evidence do you have that the Foundation has been
  hurting the evolution of Bitcoin? @p{»»}

  @p{««}Because it seems to me things have been going gangbusters since the
  Foundation was formed (with all the usual chaos and drama). @p{»»}

  @p{««}Or, to be less polite to all the haters: we've all been working our
  asses off (especially Peter), to make Bitcoin a success. What have you
  anonymous cowards been doing besides spouting off about things you know
  NOTHING about? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2041}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 19:20:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=177679.msg1961256@s{hash}msg1961256
@section 3 {tx}

  @s{quotedtext}

  @p{««} Last quarter's plan: @s{(link)} @p{»»}

  @p{««}What is next: I dunno. Foundation board will be meeting all day
  before the conference, and we'll all be talking to lots of people at the
  conference to figure out what the priorities should be going forward.
  @p{»»}

  @p{««}As for excluding certain voices: "okey dokey." I listen a lot
  harder to people who are actually getting things done, and have learned
  to tune out trolls. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2042}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 19:30:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=177679.msg1961340@s{hash}msg1961340
@section 3 {tx}

  @p{««}Board meetings are board members only. If you've ever been on the
  executive team of a company or non-profit I'm sure you can appreciate
  that if you want to actually get things done (as opposed to wanting to
  talk endlessly about things) then small, focused meetings are a
  necessary evil. @p{»»}

  @p{««}The @p{(link}Bitcoin Foundation Members Only Lunch Forum@p{link)}
  is on the conference schedule.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2043}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 19:51:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=177679.msg1961489@s{hash}msg1961489
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm allergic to that kind of bureaucracy. The agenda will probably
  be decided ten minutes before the meeting, and will probably be
  something like "Peter talks for ten minutes and answers questions for 20
  minutes while everybody is eating. Then we all talk to each other about
  whatever we like." @p{»»}

  @p{««}One day maybe the Foundation will be big and bloated, and will have
  lots of staff to prepare Official Agendas, solicit feedback from members
  months in advance, tabulate the responses, then hire a consultant to
  figure out how to increase the number of responses received, etc. @p{»»}

  @p{««}I hope I'm not on the Board any more when that happens. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2044}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-27 23:04:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=177679.msg1962752@s{hash}msg1962752
@section 3 {tx}

  @s{quotedtext}

  @p{««} Let me guess, you think 9/11 was an inside job by the Bush
  administration and we never sent a man to the moon? @p{»»}

  @p{««}This is exactly why I don't come here much any more, and exactly
  why the Foundation forums are real-name-only, member-only. None of us
  have time to respond to all the tinfoil-hat-wearing conspiracy-mongering
  (I don't remember why "Bitcoin Foundation" was originally a legal entity
  in the midwest; something about an aborted previous attempt to get one
  started by... maybe Mt. Gox? who cares? why does that matter? focus on
  the present and future, stop worrying about how things weren't done
  perfectly in the past exactly how you wanted them to happen). @p{»»}

  @p{««}Sigh. Ok, I'm going to go back to my default "don't feed the
  trolls" now, and actually get some work done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2045}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-28 17:37:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=189792.msg1967890@s{hash}msg1967890
@section 3 {tx}

  @p{««}My reaction: stop spreading FUD. @p{»»}

  @p{««}"small mining pools will go out of business" @p{--} give me a
  break! My back-of-the-envelope calculations say that anybody willing to
  spend a few hundred dollars a year on a dedicated server with a
  high-bandwidth connection can support a MUCH, MUCH larger block size.
  @p{»»}

  @p{««}The block size will be raised. Your video will just make a lot of
  people worried about nothing, in exactly the same way Luke-Jr's BIP17
  proposal last year (and his hyperbolic rhetoric about BIP16) did nothing
  but cause a tempest in a teapot. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2046}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 13:57:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=189792.msg1985439@s{hash}msg1985439
@section 3 {tx}

  @s{quotedtext}

  @p{««} Network bandwidth is currently growing about 20% per year, or
  roughly doubling every four years. @p{»»}

  @p{««}Satoshi's original code had a 32MB block size limit, which he
  dropped to 1MB as part of a bunch of band-aid fixes to make
  denial-of-service attacks harder. @p{»»}

  @p{««}RE: density of full nodes: In my opinion, if it is affordable to
  run a full node (less than, say, $100 per month in server costs@p{--}
  that is a trivial monthly cost for most businesses and some individuals)
  then we'll continue to see tens of thousands of full nodes. @p{»»}

  @p{««}Median cost of a dedicated server with lots of bandwidth, disk and
  CPU is @p{(link}under $100/month these days@p{link)}, which would
  support a block size at least ten times the current maximum. @p{»»}

  @p{««}And all of THAT is before even starting to think about possible
  optimizations (e.g. figure out how to mitigate the "insert malicious
  data" problem@p{--} maybe Peter Todd's security bonds would be
  helpful@p{--} and a shared DHT storing all valid transactions combined
  with bloom filters on connections could make it cheap for any one
  machine to be a fully validating node). @p{»»}

  @p{««}Please, don't listen to all of the FUD being thrown around about
  raising the block size even before there is any solid proposal for what
  should be done. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2047}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 14:03:57
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191425.msg1985498@s{hash}msg1985498
@section 3 {tx}

  @p{««}Y'all read the pull request, yes? @p{»»}

  @p{««}So: if you have a better suggestion for fixing the problem of new
  users wasting lots of time gathering tiny drips and drabs of bitcoins,
  and then getting upset when they can't spend them (because it costs more
  in fees that they are worth), I'm open to suggestions. @p{»»}

  @p{««}RE: "what about when bitcoins are worth a million dollars apiece"
  @p{»»}

  @p{««}Umm, that's what the "un-hardcode TX_FEE constants" part is all
  about? @p{»»}

  @p{««}RE: trolling about Foundation setting the fee: @p{»»}

  @p{««}Go back under your rock, please. This pull request is the first
  step towards a market between miners (who want higher fees) and
  merchants/users (who want lower fees, but also want their transactions
  confirmed). Miners can already control what fees they accept, this pull
  lets users control (very clumsily, improvements on the road map) the fee
  they are willing to pay.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2048}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 14:13:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=145496.msg1985563@s{hash}msg1985563
@section 3 {tx}

  @p{««}A transaction is final if: @p{»»}

  @p{««}All of its sequence numbers are INT_MAX @p{»»}

    @p{(li}OR @p{li)} lockTime has passed. @p{»»}

  @p{««}I'm still of the opinion that non-final transactions shouldn't be
  broadcast over the p2p network; I think the parties negotiating using
  them should keep them to themselves until they are final, and broadcast
  then. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2049}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 15:30:04
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191765.msg1986115@s{hash}msg1986115
@section 3 {tx}

  @p{««}Bitcoin Foundation uses CloudFlare to protect bitcoinfoundation.org
  from distributed denial of service attacks. @p{»»}

  @p{««}As the message says, either your computer or a computer on the same
  network / ISP as yours was sending lots of spammy requests to
  CloudFlare. So they ask you to solve a CAPTCHA to prove that you're not
  part of the bad guy's botnet. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2050}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 18:48:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191425.msg1987832@s{hash}msg1987832
@section 3 {tx}

  @s{quotedtext}

  @p{««} Minimum transaction output is (conservatively) calculated from the
  minimum relay fee setting. It did exist before, it was just set to '1
  satoshi'. @p{»»}

  @p{««}We made 0-satoshi outputs non-standard a couple of releases ago,
  but consensus is that was a mistake@p{--} 1-satoshi is not the right
  number, because the marginal cost of spending a 1-satoshi output is
  greater than its value. @p{»»}

  @p{««}Again, eventually it might be economical to spend 1-satoshi
  outputs. When it is, the minimum relay fee will be on the order of a
  satoshi or two, and this code will do the right thing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2051}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-04-30 18:51:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=191425.msg1987855@s{hash}msg1987855
@section 3 {tx}

  @p{««}RE: NODE_RELAYCOST : @p{»»}

  @p{««}I'm generally against any "take my word for it" settings. What
  would stop somebody Up To No Good from setting NODE_RELAYCOST and then
  lying about what they will relay? Miners might decide to try to increase
  fees by Sybil-attacking the network and lying about NODE_RELAYCOST....
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2052}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-01 02:13:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=179464.msg1990810@s{hash}msg1990810
@section 3 {tx}

  @s{quotedtext}

  @p{««} Sure. That's one of the reasons why I'm reluctant to upgrade the
  distro/dependencies for the deterministic build process, and generally
  prefer to use older dependencies rather than the "latest and greatest"
  of everything. But there's a tradeoff between "risk that an Evil
  Maintainer slipped something in" and "risk that we ship with an upatched
  bug" @p{--} e.g. we tend to be on the latest version of OpenSSL, but a
  few releases behind of Qt4. @p{»»}

  @p{««}PS: if you really want to be completely paranoid, you should only
  run bitcoin on old hardware/OS manufactured before 2009 so you can be
  sure the hardware/firmware/OS doesn't have any wallet-stealing
  circuits/code lurking.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2053}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-01 02:24:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=192181.msg1990885@s{hash}msg1990885
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}If you want to get geeky about it, it sends an ECDSA signature
  derived from the private key and the transaction data, and the full
  public key that corresponds to your bitcoin address (the address is a
  shorter version of it). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2054}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-02 17:25:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=192880.msg2007067@s{hash}msg2007067
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, please, feedback from re-implementors is very helpful. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2055}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-03 23:31:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=192880.msg2020116@s{hash}msg2020116
@section 3 {tx}

  @s{quotedtext}

  @p{««} Ummm... it is a wiki. They should just update it themselves (after
  asking questions if they have any), it is much more efficient.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2056}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-05 16:31:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=189350.msg2037447@s{hash}msg2037447
@section 3 {tx}

  @s{quotedtext}

  @p{««} Awww, that is cheating! @p{»»}

  @p{««}You really have no business creating your own block chain if you
  don't understand the code well enough to figure out how to mine a new
  genesis block without somebody else's help. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2057}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-06 02:02:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=196138.msg2042890@s{hash}msg2042890
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}Knock yourselves out, no fork needed, just add this to your
  bitcoin.conf and convince a few big miners or mining pools to do the
  same: @p{»»}

  @p{««} minrelaytxfee=0 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2058}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-06 02:12:41
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=196367.msg2042966@s{hash}msg2042966
@section 3 {tx}

  @s{quotedtext}

  @p{««} Nah, I'm not in the underground facility any more. I packed up the
  hookers and blow and we're all living the sweet life in a penthouse
  suite now. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2059}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-06 03:54:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=195642.msg2043717@s{hash}msg2043717
@section 3 {tx}

  @s{quotedtext}

  @p{««}... hire a lawyer.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2060}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-09 19:19:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=199947.msg2090345@s{hash}msg2090345
@section 3 {tx}

  @p{««}I think this is a terrible idea. @p{»»}

  @p{««}If it was "higher fee with superset of outputs of first spend" then
  that'd be fine. @p{»»}

  @p{««}Zero-confirmation transactions will never be safe because of
  potential Finney attacks. But we don't need (and, in my opinion,
  shouldn't) make them less safe by encouraging anti-social behavior via
  default mining policy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2061}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-10 04:10:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=179612.msg2094825@s{hash}msg2094825
@section 3 {tx}

  @s{quotedtext}

  @p{««} +1 

# ----------------------------------------------------------------------
@section 2 {ms2062}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-10 15:41:52 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=201124.msg2099828@s{hash}msg2099828
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.2 release candidate 1 is now available from:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release that fixes many bugs and includes
  @p{brk} a few small new features. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} @p{(ul}How to Upgrade@p{??)} @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.2 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

  @p{««}@p{(ul}@p{(bf}0.8.2 Release notes@p{bf)}@p{??)} @p{»»}

  @p{««}@p{(ul}Fee Policy changes@p{??)} @p{»»}

  @p{««}The default fee for low-priority transactions is lowered from
  0.0005 BTC @p{brk} (for each 1,000 bytes in the transaction; an average
  transaction is @p{brk} about 500 bytes) to 0.0001 BTC. @p{»»}

  @p{««}Payments (transaction outputs) of 0.543 times the minimum relay fee
  @p{brk} (0.00005430 BTC) are now considered 'non-standard', because
  storing them @p{brk} costs the network more than they are worth and
  spending them will usually @p{brk} cost their owner more in transaction
  fees than they are worth. @p{»»}

  @p{««}Non-standard transactions are not relayed across the network, are
  not included @p{brk} in blocks by most miners, and will not show up in
  your wallet until they are @p{brk} included in a block. @p{»»}

  @p{««}The default fee policy can be overridden using the -mintxfee and
  -minrelaytxfee @p{brk} command-line options, but note that we intend to
  replace the hard-coded fees @p{brk} with code that automatically
  calculates and suggests appropriate fees in the @p{brk} 0.9 release and
  note that if you set a fee policy significantly different from @p{brk}
  the rest of the network your transactions may never confirm. @p{»»}

  @p{««}@p{(ul}Bitcoin-Qt changes@p{??)} @p{»»}

  @p{««}* New icon and splash screen @p{brk} * Improve reporting of
  synchronization process @p{brk} * Remove hardcoded fee recommendations
  @p{brk} * Improve metadata of executable on MacOSX and Windows @p{brk} *
  Move export button to individual tabs instead of toolbar @p{brk} * Add
  "send coins" command to context menu in address book @p{brk} * Add "copy
  txid" command to copy transaction IDs from transaction overview @p{brk}
  * Save &amp; restore window size and position when showing &amp; hiding
  window @p{brk} * New translations: Arabic (ar), Bosnian (bs), Catalan
  (ca), Welsh (cy), @p{»»}

    @p{(li}Esperanto (eo), Interlingua (la), Latvian (lv) and many
    improvements @p{li)}

    @p{(li}to current translations @p{li)}

  @p{««}MacOSX: @p{brk} * OSX support for click-to-pay (bitcoin:) links
  @p{brk} * Fix GUI disappearing problem on MacOSX (issue @s{hash}1522) @p{»»}

  @p{««}Linux/Unix: @p{brk} * Copy addresses to middle-mouse-button
  clipboard @p{»»}

  @p{««} @p{(ul}Command-line options@p{??)} @p{»»}

  @p{««}* -walletnotify will call a command on receiving transactions that
  affect the wallet. @p{brk} * -alertnotify will call a command on
  receiving an alert from the network. @p{brk} * -par now takes a negative
  number, to leave a certain amount of cores free. @p{»»}

  @p{««}@p{(ul}JSON-RPC API changes@p{??)} @p{»»}

  @p{««}* listunspent now lists account and address infromation. @p{brk} *
  getinfo now also returns the time adjustment estimated from your peers.
  @p{brk} * getpeerinfo now returns bytessent, bytesrecv and syncnode.
  @p{brk} * gettxoutsetinfo returns statistics about the unspent
  transaction output database. @p{brk} * gettxout returns information
  about a specific unspent transaction output. @p{»»}

  @p{««} @p{(ul}Networking changes@p{??)} @p{»»}

  @p{««}* Significant changes to the networking code, reducing latency and
  memory consumption. @p{brk} * Avoid initial block download stalling.
  @p{brk} * Remove IRC seeding support. @p{brk} * Performance tweaks.
  @p{brk} * Added testnet DNS seeds. @p{»»}

  @p{««}@p{(ul}Wallet compatibility/rescuing@p{??)} @p{»»}

  @p{««}* Cases where wallets cannot be opened in another
  version/installation should be reduced. @p{brk} * -salvagewallet now
  works for encrypted wallets. @p{»»}

  @p{««} @p{(ul}@p{(bf}Thanks to everybody who contributed to the 0.8.2
  release!@p{bf)}@p{??)} @p{»»}

  @p{««}APerson241 @p{brk} Andrew Poelstra @p{brk} Calvin Owens @p{brk}
  Chuck LeDuc Diaz @p{brk} Colin Dean @p{brk} David Griffith @p{brk} David
  Serrano @p{brk} Eric Lombrozo @p{brk} Gavin Andresen @p{brk} Gregory
  Maxwell @p{brk} Jeff Garzik @p{brk} Jonas Schnelli @p{brk} Larry Gilbert
  @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk}
  Mike Hearn @p{brk} Patrick Brown @p{brk} Peter Todd @p{brk} Philip
  Kaufmann @p{brk} Pieter Wuille @p{brk} Richard Schwab @p{brk} Roman
  Mindalev @p{brk} Scott Howard @p{brk} Tariq Bashir @p{brk} Wladimir J.
  van der Laan @p{brk} freewil @p{brk} gladoscc @p{brk} kjj2 @p{brk}
  mb300sd @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2063}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-10 16:44:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=196138.msg2100394@s{hash}msg2100394
@section 3 {tx}

  @s{quotedtext}

  @p{««} Who gets to decide how slow is too slow? @p{»»}

  @p{««}Mining these days requires investing in ASIC hardware. Solo mining
  or running a pool will very soon require investing in a reasonably fast
  network connection and a machine with at least a few gigabytes of
  memory. @p{»»}

  @p{««}Knocking the slowest N% of solo miners/pools off the network every
  year (where N is less than 20 or so) is not a crisis. That is the way
  free-market competition works.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2064}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-11 18:43:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=196138.msg2113288@s{hash}msg2113288
@section 3 {tx}

  @s{quotedtext}

  @s{quotedtext}

  @p{««}Okey dokey. @p{»»}

  @p{««}Have you contributed any patches to p2pool to make it more
  efficient / easier to install / etc? If not, why not if you're so
  worried about centralization? @p{»»}

  @p{««}(honest question, I don't keep up with p2pool development because
  I'm personally not terribly worried about mining centralization) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2065}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-11 19:00:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=202111.msg2113412@s{hash}msg2113412
@section 3 {tx}

  @p{««}If there is a longer fork with more work that your node thinks is
  invalid, you'll get this alert: @p{»»}

  @p{««} Warning: Displayed transactions may not be correct! You may need
  to upgrade, or other nodes may need to upgrade. @p{»»}

  @p{««}(see the GetWarnings() function in main.cpp). @p{»»}

  @p{««}If you are on the fork with the most work... I suppose if the
  second-best chain was forked more than 6 blocks back and contained more
  than... oh, 5 blocks and the timestamp on the last block in that chain
  was less than ?an hour ago? that could trigger another alert. @p{»»}

  @p{««}All that might be tricky to implement@p{--} either (or both) forks
  might themselves have forks. Or, theoretically, there could be three or
  more active forks, some of which might have equal proof-of-work... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2066}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-13 14:45:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=203989.msg2132193@s{hash}msg2132193
@section 3 {tx}

  @s{quotedtext}

  @p{««} You are wrong. If Bitcoin was using (double) MD5 for its
  proof-of-work hashing algorithm, we'd be just fine.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2067}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-21 19:54:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=210130.msg2226486@s{hash}msg2226486
@section 3 {tx}

  @p{««}Couple years ago it was "Don't talk to the CIA! They're Evil, and
  will Destroy Bitcoin!" @p{»»}

  @p{««}Now it is "Don't get involved in DC lobbying! That's Evil, and will
  Destroy Bitcoin!" @p{»»}

  @p{««}In a few more years, I bet it'll be "Don't go to the United
  Nations! They're Evil, and will Destroy Bitcoin!" @p{»»}

  @p{««}I'll quote myself from a related thread on google+ @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms2068}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-21 20:37:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=212380.msg2226916@s{hash}msg2226916
@section 3 {tx}

  @p{««}Yes, after NUMEQUALVERIFY the stack will be empty, and for a script
  to be valid it must leave a true value on the stack. @p{»»}

  @p{««}Use NUMEQUAL and it should work. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2069}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-22 18:19:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=212758.msg2237019@s{hash}msg2237019
@section 3 {tx}

  @s{quotedtext}

  @p{««} I received my pre-ordered (day 2, I think) Jalapeno today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2070}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-24 21:59:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=214883.msg2260402@s{hash}msg2260402
@section 3 {tx}

  @s{quotedtext}

  @p{««} Except they're not learning from Bitcoin's mistakes; how many alt
  coins have fixed the problems on Bitcoin's @p{(link}hard-fork wish
  list@p{link)}?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2071}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-24 23:05:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=215480.msg2261095@s{hash}msg2261095
@section 3 {tx}

  @p{««}0.8.2 rc2 never made it out the door; two crash-on-shutdown bugs
  and a bitcoin.ico file that made the windows gitian build
  non-reproducible made us jump to rc3 instead. @p{»»}

  @p{««}So: @p{»»}

  @p{««}Bitcoin-Qt version 0.8.2 release candidate 3 is now available from:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release that fixes many bugs and includes
  @p{brk} a few small new features. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.2 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

  @p{««}0.8.2 Release notes @p{»»}

  @p{««}Fee Policy changes  @p{»»}

  @p{««}The default fee for low-priority transactions is lowered from
  0.0005 BTC @p{brk} (for each 1,000 bytes in the transaction; an average
  transaction is @p{brk} about 500 bytes) to 0.0001 BTC. @p{»»}

  @p{««}Payments (transaction outputs) of 0.543 times the minimum relay fee
  @p{brk} (0.00005430 BTC) are now considered 'non-standard', because
  storing them @p{brk} costs the network more than they are worth and
  spending them will usually @p{brk} cost their owner more in transaction
  fees than they are worth. @p{»»}

  @p{««}Non-standard transactions are not relayed across the network, are
  not included @p{brk} in blocks by most miners, and will not show up in
  your wallet until they are @p{brk} included in a block. @p{»»}

  @p{««}The default fee policy can be overridden using the -mintxfee and
  -minrelaytxfee @p{brk} command-line options, but note that we intend to
  replace the hard-coded fees @p{brk} with code that automatically
  calculates and suggests appropriate fees in the @p{brk} 0.9 release and
  note that if you set a fee policy significantly different from @p{brk}
  the rest of the network your transactions may never confirm. @p{»»}

  @p{««}Bitcoin-Qt changes  @p{»»}

  @p{««}* New icon and splash screen @p{brk} * Improve reporting of
  synchronization process @p{brk} * Remove hardcoded fee recommendations
  @p{brk} * Improve metadata of executable on MacOSX and Windows @p{brk} *
  Move export button to individual tabs instead of toolbar @p{brk} * Add
  "send coins" command to context menu in address book @p{brk} * Add "copy
  txid" command to copy transaction IDs from transaction overview @p{brk}
  * Save &amp; restore window size and position when showing &amp; hiding
  window @p{brk} * New translations: Arabic (ar), Bosnian (bs), Catalan
  (ca), Welsh (cy), @p{»»}

    @p{(li}Esperanto (eo), Interlingua (la), Latvian (lv) and many
    improvements @p{li)}

    @p{(li}to current translations @p{li)}

  @p{««}MacOSX: @p{brk} * OSX support for click-to-pay (bitcoin:) links
  @p{brk} * Fix GUI disappearing problem on MacOSX (issue @s{hash}1522) @p{»»}

  @p{««}Linux/Unix: @p{brk} * Copy addresses to middle-mouse-button
  clipboard @p{»»}

  @p{««} Command-line options @p{»»}

  @p{««}* -walletnotify will call a command on receiving transactions that
  affect the wallet. @p{brk} * -alertnotify will call a command on
  receiving an alert from the network. @p{brk} * -par now takes a negative
  number, to leave a certain amount of cores free. @p{»»}

  @p{««}JSON-RPC API changes  @p{»»}

  @p{««}* fixed a getblocktemplate bug that caused excessive CPU creating
  blocks. @p{brk} * listunspent now lists account and address infromation.
  @p{brk} * getinfo now also returns the time adjustment estimated from
  your peers. @p{brk} * getpeerinfo now returns bytessent, bytesrecv and
  syncnode. @p{brk} * gettxoutsetinfo returns statistics about the unspent
  transaction output database. @p{brk} * gettxout returns information
  about a specific unspent transaction output. @p{»»}

  @p{««} Networking changes @p{»»}

  @p{««}* Significant changes to the networking code, reducing latency and
  memory consumption. @p{brk} * Avoid initial block download stalling.
  @p{brk} * Remove IRC seeding support. @p{brk} * Performance tweaks.
  @p{brk} * Added testnet DNS seeds. @p{»»}

  @p{««}Wallet compatibility/rescuing @p{»»}

  @p{««}* Cases where wallets cannot be opened in another
  version/installation should be reduced. @p{brk} * -salvagewallet now
  works for encrypted wallets. @p{»»}

  @p{««} Thanks to everybody who contributed to the 0.8.2 release! @p{»»}

  @p{««}APerson241 @p{brk} Andrew Poelstra @p{brk} Calvin Owens @p{brk}
  Chuck LeDuc Diaz @p{brk} Colin Dean @p{brk} David Griffith @p{brk} David
  Serrano @p{brk} Eric Lombrozo @p{brk} Gavin Andresen @p{brk} Gregory
  Maxwell @p{brk} Jeff Garzik @p{brk} Jonas Schnelli @p{brk} Larry Gilbert
  @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk}
  Mike Hearn @p{brk} Patrick Brown @p{brk} Peter Todd @p{brk} Philip
  Kaufmann @p{brk} Pieter Wuille @p{brk} Richard Schwab @p{brk} Roman
  Mindalev @p{brk} Scott Howard @p{brk} Tariq Bashir @p{brk} Warren Togami
  @p{brk} Wladimir J. van der Laan @p{brk} freewil @p{brk} gladoscc
  @p{brk} kjj2 @p{brk} mb300sd @p{brk} super3 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2072}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-27 16:20:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=215480.msg2286434@s{hash}msg2286434
@section 3 {tx}

  @p{««}latency of what? getblocktemplate? getbalance? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2073}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-29 21:20:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=219504.msg2311420@s{hash}msg2311420
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.2 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release that fixes many bugs and includes
  @p{brk} a few small new features. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} @p{(ul}@p{(bf}How to Upgrade@p{bf)}@p{??)} @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.2 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

  @p{««}@p{(ul}@p{(bf}0.8.2 Release notes@p{bf)}@p{??)} @p{»»}

  @p{««}@p{(ul}Fee Policy changes@p{??)} @p{»»}

  @p{««}The default fee for low-priority transactions is lowered from
  0.0005 BTC @p{brk} (for each 1,000 bytes in the transaction; an average
  transaction is @p{brk} about 500 bytes) to 0.0001 BTC. @p{»»}

  @p{««}Payments (transaction outputs) of 0.543 times the minimum relay fee
  @p{brk} (0.00005430 BTC) are now considered 'non-standard', because
  storing them @p{brk} costs the network more than they are worth and
  spending them will usually @p{brk} cost their owner more in transaction
  fees than they are worth. @p{»»}

  @p{««}Non-standard transactions are not relayed across the network, are
  not included @p{brk} in blocks by most miners, and will not show up in
  your wallet until they are @p{brk} included in a block. @p{»»}

  @p{««}The default fee policy can be overridden using the -mintxfee and
  -minrelaytxfee @p{brk} command-line options, but note that we intend to
  replace the hard-coded fees @p{brk} with code that automatically
  calculates and suggests appropriate fees in the @p{brk} 0.9 release and
  note that if you set a fee policy significantly different from @p{brk}
  the rest of the network your transactions may never confirm. @p{»»}

  @p{««}@p{(ul}Bitcoin-Qt changes@p{??)} @p{»»}

  @p{««}* New icon and splash screen @p{brk} * Improve reporting of
  synchronization process @p{brk} * Remove hardcoded fee recommendations
  @p{brk} * Improve metadata of executable on MacOSX and Windows @p{brk} *
  Move export button to individual tabs instead of toolbar @p{brk} * Add
  "send coins" command to context menu in address book @p{brk} * Add "copy
  txid" command to copy transaction IDs from transaction overview @p{brk}
  * Save &amp; restore window size and position when showing &amp; hiding
  window @p{brk} * New translations: Arabic (ar), Bosnian (bs), Catalan
  (ca), Welsh (cy), @p{»»}

    @p{(li}Esperanto (eo), Interlingua (la), Latvian (lv) and many
    improvements @p{li)}

    @p{(li}to current translations @p{li)}

  @p{««}MacOSX: @p{brk} * OSX support for click-to-pay (bitcoin:) links
  @p{brk} * Fix GUI disappearing problem on MacOSX (issue @s{hash}1522) @p{»»}

  @p{««}Linux/Unix: @p{brk} * Copy addresses to middle-mouse-button
  clipboard @p{»»}

  @p{««} @p{(ul}Command-line options@p{??)} @p{»»}

  @p{««}* -walletnotify will call a command on receiving transactions that
  affect the wallet. @p{brk} * -alertnotify will call a command on
  receiving an alert from the network. @p{brk} * -par now takes a negative
  number, to leave a certain amount of cores free. @p{»»}

  @p{««}@p{(ul}JSON-RPC API changes@p{??)} @p{»»}

  @p{««}* fixed a getblocktemplate bug that caused excessive CPU creating
  blocks. @p{brk} * listunspent now lists account and address infromation.
  @p{brk} * getinfo now also returns the time adjustment estimated from
  your peers. @p{brk} * getpeerinfo now returns bytessent, bytesrecv and
  syncnode. @p{brk} * gettxoutsetinfo returns statistics about the unspent
  transaction output database. @p{brk} * gettxout returns information
  about a specific unspent transaction output. @p{»»}

  @p{««} @p{(ul}Networking changes@p{??)} @p{»»}

  @p{««}* Significant changes to the networking code, reducing latency and
  memory consumption. @p{brk} * Avoid initial block download stalling.
  @p{brk} * Remove IRC seeding support. @p{brk} * Performance tweaks.
  @p{brk} * Added testnet DNS seeds. @p{»»}

  @p{««}@p{(ul}Wallet compatibility/rescuing@p{??)} @p{»»}

  @p{««}* Cases where wallets cannot be opened in another
  version/installation should be reduced. @p{brk} * -salvagewallet now
  works for encrypted wallets. @p{»»}

  @p{««} @p{(ul}Known Bugs@p{??)} @p{»»}

  @p{««}* Entering the 'getblocktemplate' or 'getwork' RPC commands into
  the Bitcoin-Qt debug @p{brk} console will cause Bitcoin-Qt to crash. Run
  Bitcoin-Qt with the -server command-line @p{brk} option to workaround.
  @p{»»}

  @p{««}@p{(bf}@p{(ul}Thanks to everybody who contributed to the 0.8.2
  release!@p{??)}@p{bf)} @p{»»}

  @p{««}APerson241 @p{brk} Andrew Poelstra @p{brk} Calvin Owens @p{brk}
  Chuck LeDuc Diaz @p{brk} Colin Dean @p{brk} David Griffith @p{brk} David
  Serrano @p{brk} Eric Lombrozo @p{brk} Gavin Andresen @p{brk} Gregory
  Maxwell @p{brk} Jeff Garzik @p{brk} Jonas Schnelli @p{brk} Larry Gilbert
  @p{brk} Luke Dashjr @p{brk} Matt Corallo @p{brk} Michael Ford @p{brk}
  Mike Hearn @p{brk} Patrick Brown @p{brk} Peter Todd @p{brk} Philip
  Kaufmann @p{brk} Pieter Wuille @p{brk} Richard Schwab @p{brk} Roman
  Mindalev @p{brk} Scott Howard @p{brk} Tariq Bashir @p{brk} Warren Togami
  @p{brk} Wladimir J. van der Laan @p{brk} freewil @p{brk} gladoscc
  @p{brk} kjj2 @p{brk} mb300sd @p{brk} super3 @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2074}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-30 13:15:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=175156.msg2318052@s{hash}msg2318052
@section 3 {tx}

  @p{««}I've started and then stopped writing about Zerocoin three or four
  times now; my thoughts about it are still muddled. @p{»»}

  @p{««}It adds a whole lot of complexity to transaction
  creation/verification to solve one problem: how to mix
  coins/transactions with zero trust in the mixing process. That's
  technically nifty, but I wonder if it is the best engineering solution.
  @p{»»}

  @p{««}I wonder if just using a couple of semi-trusted mixers would be a
  lot faster/smaller/simpler. @p{»»}

  @p{««}And then I start thinking about "tainted coins" in general. If we
  imagine a world with either mandatory or voluntary "taint tracking" (I
  have no idea whether or not that will ever happen), then it seems to me
  any mixing scheme that isn't "always on" is likely to fail in
  practice@p{--} all coins coming out of the mix will be considered
  tainted. @p{»»}

  @p{««}Why? I assume that most users (if you are reading this are
  @p{(bf}NOT@p{bf)} "most users") don't care much about privacy/anonymity.
  So I would assume most people would choose the lowest cost, fastest,
  most convenient method for their transactions. Anybody using a mixer
  will be either a weirdo, principled privacy nut (like us) or a criminal.
  I don't see other "privacy first" projects taking over the world, but do
  see lots of big, successful "quick and easy and free" projects. @p{»»}

  @p{««}Then my thoughts get muddled, because "it is hopeless, just give
  up" is not an answer I'm willing to accept. But it feels to me like
  finding an essentially zero-cost way to increase transaction privacy
  that everybody uses by default is the best answer. Making your network
  connection more private is the other piece of the puzzle, though, and
  all of the solutions for that (either route through a couple of
  semi-trusted proxies or use Tor or i2p) add significant
  convenience/speed/financial costs. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2075}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-30 17:38:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=220273.msg2320603@s{hash}msg2320603
@section 3 {tx}

  @s{quotedtext}

  @p{««} Security, yes (including potential for denial-of-service attacks
  of various sorts). @p{»»}

  @p{««}But demonstrate a spiffy, compelling use of new opcodes on testnet
  and we'll talk about making them standard. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2076}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-05-31 00:16:13
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=220530.msg2324290@s{hash}msg2324290
@section 3 {tx}

  @s{quotedtext}

  @p{««} How do you prevent Sybil attacks@p{--} somebody creating a
  gazillion n-client and/or hatching nodes, and voting themselves lots and
  lots of new currency? @p{»»}

  @p{««}And how does a node choose a "random" node@p{--} does every node
  know about every other node? If yes, then how do you avoid getting
  O(N^2) communication as the number of nodes (N) rises and every existing
  node must be told about every new node? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2077}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-03 16:44:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221111.msg2359724@s{hash}msg2359724
@section 3 {tx}

  @p{««}The block size will be raised, that is the overwhelming consensus
  among the people who are actually writing code and using Bitcoin for
  products and services that it needs to happen. @p{»»}

  @p{««}And there is a tiny minority of people who will loudly proclaim
  that isn't true and that the core developer are going to destroy Bitcoin
  if the block size is raised. @p{»»}

  @p{««}If you want to be helpful, please organize a list of objections to
  raising the block size limit and responses to those objections. @p{»»}

  @p{««}I believe the last objection raised was that a higher block size
  limit would make it impossible to mine anonymously, but I think that has
  been debunked with the notion of "read the firehose of transactions
  non-anonymously, then broadcast just new block header + coinbase +
  listof(truncated transaction hashes) anonymously." @p{»»}

  @p{««}I'll soon be writing up a plan for how we can safely raise the
  block size limit. @p{»»}

  @p{««} RE: central planning: @p{»»}

  @p{««}No central planning is why I would like to eliminate the hard,
  upper blocksize limit entirely, and let the network decide "how big is
  too big." @p{»»}

  @p{««}RE: "the plan" : The plan from the beginning was to support huge
  blocks. The 1MB hard limit was always a temporary denial-of-service
  prevention measure. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2078}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-03 16:47:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=223007.msg2359756@s{hash}msg2359756
@section 3 {tx}

  @p{««}Thanks! @p{»»}

  @p{««}PS: I'm still giving away 10 BTC per month from those funds to the
  Minecraft Faucet (I committed 100BTC to the Minecraft Faucet folks
  before the EFF announced they'd accept Bitcoin donations again)...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2079}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-03 18:53:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221111.msg2360913@s{hash}msg2360913
@section 3 {tx}

  @s{quotedtext}

  @p{««} Which "bigger powers" and which "people" ? @p{»»}

  @p{««}Is there some secret cabal out there I don't know about? @p{»»}

  @p{««}If you mean "Peter Todd has convinced some big mining pool
  operators not to increase the size of the blocks they create" @p{--}
  then great! That's the free market at work, big mining pools should be
  free to create blocks that are as large or as small as they like, and to
  accept or reject other's blocks for whatever reason they like. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2080}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-03 20:18:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221111.msg2361639@s{hash}msg2361639
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, absolutely not. The process for a hard fork looks like: @p{»»}

  @p{(li}  Get rough consensus that the change is necessary.  @p{li)}

    @p{(li}@p{(li} Write the code. @p{li)} @p{(li} Get it reviewed and
    thoroughly tested. @p{li)} @p{(li} Release software that will support
    it when X% of hashing power agrees @p{li)}

  @p{««}... where X is a super-majority (like 75% or more). If 70% of
  hashing power disagrees, then it doesn't happen. Miners will express
  support by producing block.version=3 blocks (just like they are now
  producing block.version=2 blocks that MUST include the chain height in
  the coinbase transaction). @p{»»}

  @p{««}It is possible the X% threshold will never happen if 1MB is plenty
  big enough. It is possible it will only happen when transaction fees
  start going up and pressure increases on pools to make their blocks
  bigger (or maybe merchants tired of paying high fees figure out they'll
  save money by mining or operating pools themselves, will get X% of
  hashing power, and will increase the block size). @p{»»}

  @p{««}Again, I spent a lot of time at the conference talking with people
  about the block size issue, and there is definitely consensus that 1MB
  just won't be big enough eventually. That has nothing to do with
  microtransactions, normal growth in "macrotransactions" will bump up
  against the limit in a year or three. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2081}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-04 14:38:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=225236.msg2368959@s{hash}msg2368959
@section 3 {tx}

  @p{««}Selling my @p{(link}Butterfly Labs BitForce 5 GH/s SC@p{link)} (aka
  Jalapeno) ASIC miner. @p{»»}

  @p{««}It has been reliably cranking out about 5 and a half GH/s at about
  35 watts for @p{brk} two weeks now; I'm selling it just so I have one
  less thing in my life to think about. @p{»»}

  @p{««}I paid 25.9 BTC for it; best offer over 26 BTC before 16:00 UTC
  Sunday, 9 June gets it. @p{brk} I'll ship it UPS/USPS/Fedex on the 10'th
  or 11'th, you must pay shipping (e.g. if you @p{brk} want it overnight,
  add shipping charges from Amherst, MA 01002 to your payment). @p{»»}

  @p{««}PGP signed version of the above, so you know this is really me and
  not a scammer who managed to hack my forum account: @p{»»}

  @s{code}

  @p{««}Selling my Butterfly Labs BitForce 5 GH/s SC (aka Jalapeno) ASIC
  miner. @p{»»}

  @p{««}It has been reliably cranking out about 5 and a half GH/s at about
  35 watts for @p{brk} two weeks now; I'm selling it just so I have one
  less thing in my life to think about. @p{»»}

  @p{««}I paid 25.9 BTC for it; best offer over 26 BTC before 16:00 UTC
  Sunday, 9 June gets it. @p{brk} I'll ship it UPS/USPS/Fedex on the 10'th
  or 11'th, you must pay shipping (e.g. if you @p{brk} want it overnight,
  add shipping charges from Amherst, MA 01002 to your payment). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2082}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-04 14:46:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221111.msg2369053@s{hash}msg2369053
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm doing well this month, so far I've been called an "Angry
  Internet Troll", a "coward", and a "nazi". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2083}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-04 17:59:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=221111.msg2370887@s{hash}msg2370887
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. If you're feeling helpful, please create a wiki page or other
  document that organizes all of the pro/con arguments: economic and
  technical. And maybe another wiki page that organizes all of the various
  proposals for how to increase the block size. @p{»»}

  @p{««}I've been derailed the last week by a @p{(link}death in the
  family@p{link)}, and still need to finish up some payment protocol
  work.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2084}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-05 17:05:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=226196.msg2380783@s{hash}msg2380783
@section 3 {tx}

  @s{quotedtext}

  @p{««} This gives me warm fuzzies; a University of Chicago professor
  speculating about how a wildly successful Bitcoin might affect the
  International Monetary Fund! @p{»»}

  @p{««}I don't really care what is said, just the fact that Bitcoin is
  being talked about in the elite Ivory Towers is a very good thing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2085}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-06 17:00:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=225236.msg2391744@s{hash}msg2391744
@section 3 {tx}

  @s{quotedtext}

  @p{««}It is mining over 0.2 BTC per day right now, so if difficulty
  doesn't change (HAH!) and you have free electricity (DOUBLE HAH!) you'll
  break even in 4 or 5 months. @p{»»}

  @p{««}PS: best offer so far is a private offer of 26 BTC plus shipping.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2086}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-06 17:16:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=225025.msg2391885@s{hash}msg2391885
@section 3 {tx}

  @s{quotedtext}

  @p{««} Pieter and Wladimir are not US citizens, so a US judge can't order
  them to do anything. @p{»»}

  @p{««}If I was ordered to insert a backdoor, I'd just resign as lead
  developer and find something else to work on. @p{»»}

  @p{««}But this whole scenario sounds like a paranoid delusion; has there
  EVER been a case where a judge has ordered a software developer to do
  anything other than stop distributing their software (because of some
  copyright or patent issue) ?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2087}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-09 16:36:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=225236.msg2421695@s{hash}msg2421695
@section 3 {tx}

  @p{««}Sold! (I hope) @p{»»}

  @p{««}Two offers over 26 BTC, best offer was 30 BTC. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2088}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-09 16:38:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=229405.msg2421712@s{hash}msg2421712
@section 3 {tx}

  @p{««}No.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2089}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-06-25 17:59:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=242848.msg2576988@s{hash}msg2576988
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.3 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release to fix a denial-of-service attack
  that @p{brk} can cause nodes to crash. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}@p{(it}@p{(bf}0.8.3 Release notes@p{bf)}@p{it)} @p{»»}

  @p{««}Truncate over-size messages to prevent a memory exhaustion attack.
  @p{»»}

  @p{««}Fix a regression that causes excessive re-writing of the
  'peers.dat' file. @p{»»}

  @p{««} @p{hrule} @p{brk} Thanks to Peter Todd for responsibly disclosing
  the vulnerability @p{brk} ( CVE-2013-4627 ) and creating a fix.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2090}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-08 20:09:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=251447.msg2684424@s{hash}msg2684424
@section 3 {tx}

  @p{««}The problem is that there is a mismatch between the criteria used
  to accept a transaction into the memory pool / relayed and the criteria
  most miners use to choose transactions for their blocks. @p{»»}

  @p{««}The fix is not conceptually hard; just modify the memory pool code
  so the memory pool is treated like it is an extra-large block, and only
  relay/store the transactions that are likely to be mined in the next few
  blocks. @p{»»}

  @p{««}That hasn't been implemented yet because it just hasn't been a high
  priority.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2091}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-10 06:14:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=252931.msg2696066@s{hash}msg2696066
@section 3 {tx}

  @p{««}Nice work! @p{»»}

  @p{««}RE: gcc creating different binaries: @p{»»}

  @p{««}The gitian build does two main things to make builds reproducible:
  @p{»»}

    @p{(li} 1. Uses libfaketime.so so all calls to time()/etc during
   compilation return the same time. @p{brk} (I don't know if it is the
   compiler, linker, or archiver that likes to put timestamps in binaries)
   @p{li)}

    @p{(li} 2. Passes -frandom-seed=constant to g++, so it doesn't create
    random names for generated methods. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2092}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-20 06:17:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=149479.msg2766645@s{hash}msg2766645
@section 3 {tx}

  @p{««}I spent a bunch of time getting the mingw-cross-compiled Qt
  compiled with -openssl-linked for the payment protocol work (it uses
  QtNetwork to fetch PaymentRequest/PaymentACK messages via https). @p{»»}

  @p{««}The magic configure incantation was: @p{»»}

  @s{quotedtext}

  @p{««} Nothing special needed to be done for the openssl build: @p{»»}

  @s{quotedtext}

  @p{««}The payment protocol code add a couple more depedencies to
  Bitcoin-Qt: @p{»»}

  @p{(li}  QtNetwork with OpenSSL support  @p{li)}

    @p{(li}@p{(li} Google's protocol buffer library and compiler. @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2093}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-23 22:59:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=260749.msg2791092@s{hash}msg2791092
@section 3 {tx}

  @s{quotedtext}

  @p{««} I would much rather people help test individual pull requests or
  'git HEAD' rather than "random collection of changes". Putting eleven
  unrelated changes together makes figuring out what caused a
  bug/regression much harder. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2094}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-29 00:16:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=262935.msg2822678@s{hash}msg2822678
@section 3 {tx}

  @s{quotedtext}

  @p{««} That's incorrect. The following command-line or bitcoin.conf
  configuration parameters let miners set their transaction acceptance
  policy: @p{»»}

  @s{quotedtext}

  @p{««} The -mintxfee / -minrelaytxfee options currently control how large
  a fee-per-kilobyte is needed for a transaction to be considered "fee
  paying" versus "free". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2095}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-29 00:24:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=262167.msg2822717@s{hash}msg2822717
@section 3 {tx}

  @p{««}How big is your wallet? @p{»»}

  @p{««}getbalance() is O(N) where N is the total number of transactions in
  the wallet. (actually, it can be even worse than O(N) if you have long
  chains of unconfirmed transactions in your wallet) @p{»»}

  @p{««}"Patches welcome" to fix that, I expected one of the big
  bitcoind-using services would submit a performance fix patch long ago.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2096}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-07-31 00:04:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=252931.msg2835664@s{hash}msg2835664
@section 3 {tx}

  @p{««}So, one thought: @p{»»}

  @p{««}Instead of "staging" all of the dependencies and then modifying the
  makefile/.pro to look for the dependencies in six different places, it
  would be cleaner to configure with @p{--}prefix=@p{lt}somewhere@s{gt}
  and then 'make install' to put all the dependency libraries/include
  files in one spot. Ideally, none of the makefiles/.pro files would
  contain specific version numbers for anything. @p{»»}

  @p{««}Specific notes as I worked through doing that on a Windows system,
  putting dependencies in C:\deps : @p{»»}

  @p{««}Openssl: /bin/perl Configure @p{--}prefix=/c/deps mingw ...etc
  @p{»»}

  @p{««}BDB: ../dist/configure @p{--}prefix=/c/deps ...etc @p{»»}

  @p{««}Boost: b2.exe @p{--}layout=system @p{--}prefix=C:\deps link=static
  threading=multi runtime-link=static toolset=gcc ...etc @p{»»}

  @p{««}Qt: configure.exe -prefix=C:\deps -I "C:\deps\include" -L
  "C:\deps\lib" ...etc @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2097}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-08-30 07:26:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=272577.msg3040832@s{hash}msg3040832
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, please stop polluting the UTXO set. There are much better
  ways to accomplish what you want to accomplish. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2098}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-08-30 07:29:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=284178.msg3040840@s{hash}msg3040840
@section 3 {tx}

  @p{««}It bloats the UTXO set, which is bad. @p{»»}

  @p{««}MasterCoin transactions should all be spendable or provably
  prune-able. There are plenty of ways to accomplish that, the easiest of
  which that works today would be to stuff data into unused public keys of
  an OP_CHECKMULTISIG transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2099}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-04 01:22:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287351.msg3076439@s{hash}msg3076439
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.4 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release to fix a critical bug and three
  @p{brk} security issues; we urge all users to upgrade. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.4 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

  @p{««}0.8.4 Release notes @p{»»}

  @p{««}Security issues @p{»»}

  @p{««}An attacker could send a series of messages that resulted in
  @p{brk} an integer division-by-zero error in the Bloom Filter handling
  @p{brk} code, causing the Bitcoin-Qt or bitcoind process to crash.
  @p{brk} Bloom filters were introduced with version 0.8, so versions
  0.8.0 @p{brk} through 0.8.3 are vulnerable to this critical
  denial-of-service attack. @p{»»}

  @p{««}A constant-time algorithm is now used to check RPC password @p{brk}
  guess attempts; fixes @s{(link)} @p{brk} (CVE-2013-4165) @p{»»}

  @p{««}Implement a better fix for the fill-memory-with-orphan-transactions
  @p{brk} attack that was fixed in 0.8.3. See @p{brk} @s{(link)} @p{brk}
  for a description of the weaknesses of the previous fix. @p{brk}
  (CVE-2013-4627) @p{»»}

  @p{««}Bugs fixed @p{»»}

  @p{««}Fix multi-block reorg transaction resurrection. @p{»»}

  @p{««}Fix non-standard disconnected transactions causing mempool orphans.
  @p{brk} This bug could cause nodes running with the -debug flag to
  crash. @p{»»}

  @p{««}OSX: use 'FD_FULLSYNC' with LevelDB, which will (hopefully!)
  @p{brk} prevent the database corruption issues many people have @p{brk}
  experienced on OSX. @p{»»}

  @p{««}Linux: clicking on bitcoin: links was broken if you were using
  @p{brk} a Gnome-based desktop. @p{»»}

  @p{««}Fix a hang-at-shutdown bug that only affects users that compile
  @p{brk} their own version of Bitcoin against Boost versions 1.50-1.52.
  @p{»»}

  @p{««}Other changes @p{brk}  @p{»»}

  @p{««}Checkpoint at block 250,000 to speed up initial block downloads
  @p{brk} and make the progress indicator when downloading more accurate.
  @p{»»}

  @p{««} Thanks to everybody who contributed to the 0.8.4 releases! @p{»»}

  @p{««}Pieter Wuille @p{brk} Warren Togami @p{brk} Patrick Strateman
  @p{brk} pakt @p{brk} Gregory Maxwell @p{brk} Sergio Demian Lerner
  @p{brk} grayleonard @p{brk} Cory Fields @p{brk} Matt Corallo @p{brk}
  Gavin Andresen @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2100}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-04 04:17:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287351.msg3077230@s{hash}msg3077230
@section 3 {tx}

  @s{quotedtext}

  @p{««} My build environment changed and the first -linux.tar.gz contained
  ._foo files (see @s{(link)} ). @p{»»}

  @p{««}So I untarred and re-tarred with the magic "don't be clever,
  please, OSX" environment variable set and uploaded a new .tar.gz and
  SHASUMS. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2101}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-04 04:25:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=149479.msg3077266@s{hash}msg3077266
@section 3 {tx}

  @p{««}I wrote a big comment in init.cpp describing how shutdown works:
  @p{»»}

   @s{code}

  @p{««} // @p{»»}

  @p{««} I don't know nuthin about Windows' SetConsoleCtrlHandler(), but
  just setting the fRequestShutdown global variable should do the right
  thing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2102}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-08 01:55:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=287351.msg3104709@s{hash}msg3104709
@section 3 {tx}

  @s{quotedtext}

  @p{««} Most likely explanation is one of your blockchain data files is
  corrupted, but the old version doesn't care. You might be serving up a
  corrupted blocks to anybody who downloads from you, but you wouldn't
  notice that either.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2103}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-09 06:38:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=288298.msg3111910@s{hash}msg3111910
@section 3 {tx}

  @p{««}There was an interesting research paper (which I can't find) that
  claimed that high frequency trading is largely driven by the artifically
  high limit on bid/ask spreads. The claim is that if trading was allowed
  in much smaller fractions of a dollar traders would compete by
  underbidding/overoffering instead of competing to be first in the
  trading queue. @p{»»}

  @p{««}That seems plausible to me@p{--} set an arbitrary constraint ("bids
  must be in multiples of a tenth of a penny" @p{--} or whatever it is
  these days) and you often get unintended consequences. @p{»»}

  @p{««}I still plan on writing up why I disagree with the idea that a
  larger block size will lead to centralization, but I'm working on some
  higher priority things first. I really don't understand why you would
  think that our current, arbitrary 1MB limit is the Best Size For All
  Time. I think @p{(bf}that@p{bf)} arbitrary constraint will have bad
  unintended consequences. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2104}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-13 01:14:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=293307.msg3141497@s{hash}msg3141497
@section 3 {tx}

  @p{««}Bitcoin-Qt version 0.8.5 is now available from: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}This is a maintenance release to fix @p{(link}a critical
  bug@p{link)}; @p{brk} we urge all users to upgrade. @p{»»}

  @p{««}Please report bugs using the issue tracker at github: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««} How to Upgrade @p{»»}

  @p{««}If you are running an older version, shut it down. Wait @p{brk}
  until it has completely shut down (which might take a few minutes for
  older @p{brk} versions), then run the installer (on Windows) or just
  copy over @p{brk} /Applications/Bitcoin-Qt (on Mac) or
  bitcoind/bitcoin-qt (on Linux). @p{»»}

  @p{««}If you are upgrading from version 0.7.2 or earlier, the first time
  you @p{brk} run 0.8.5 your blockchain files will be re-indexed, which
  will take @p{brk} anywhere from 30 minutes to several hours, depending
  on the speed of @p{brk} your machine. @p{»»}

  @p{««}0.8.5 Release notes @p{»»}

  @p{««}Bugs fixed @p{»»}

  @p{««}Transactions with version numbers larger than 0x7fffffff were
  @p{brk} incorrectly being relayed and included in blocks. @p{»»}

  @p{««}Blocks containing transactions with version numbers larger @p{brk}
  than 0x7fffffff caused the code that checks for LevelDB database @p{brk}
  inconsistencies at startup to erroneously report database @p{brk}
  corruption and suggest that you reindex your database. @p{»»}

  @p{««}This release also contains a non-critical fix to the code that
  @p{brk} enforces BIP 34 (block height in the coinbase transaction).
  @p{»»}

  @p{««}Thanks to Gregory Maxwell and Pieter Wuille for quickly @p{brk}
  identifying and fixing the transaction version number bug.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2105}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-15 23:36:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=183.msg3162561@s{hash}msg3162561
@section 3 {tx}

  @p{««}No, I don't have time to clean up the code, port it to the latest
  AppEngine API, etc. @p{»»}

  @p{««}The Faucet was the simplest possible project I could think of to
  get my feet wet with Bitcoin; the hard part is preventing cheaters who
  try to get more than their fair share, and I was never able to come up
  with a really good solution (that is tied into the whole
  identity-on-the-Internet thing, which @p{(bf}nobody@p{bf)} has
  solved).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2106}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-15 23:38:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128442.msg3162569@s{hash}msg3162569
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, not if you use Tor. @p{»»}

  @p{««}Tor (or i2p or some other anonymizing proxy solution) is the only
  way to keep online merchants from figuring out your IP. After all, if
  you browse to their website without Tor, then your IP is sitting right
  there in their web server logs. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2107}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-18 08:20:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=178011.msg3179711@s{hash}msg3179711
@section 3 {tx}

  @s{quotedtext}

  @p{««} "Patches welcome." @p{»»}

  @p{««}A watch-only wallet that has a bunch of public keys (and multisig
  groups of public keys) is a good idea. But first you'd need multi-wallet
  support. @p{»»}

  @p{««}There is a pull request that adds watch-only addresses, but I think
  that is the wrong way to go. Mixing up fund that can be spent with funds
  that cannot be spent (e.g. because they're a multisig escrow you want to
  watch) is a bad idea, and as soon as we have hierarchical deterministic
  wallets we'll want watch-only wallets that are derived from a master key
  (or a set of master keys in the case of multisig) where the local
  bitcoind doesn't have the private seed for the key. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2108}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-23 00:00:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=299005.msg3213333@s{hash}msg3213333
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, they can't. You just extend the taint-tracking through the
  newly minted coins (e.g. if you try to "melt" 75 BTC with the 25 BTC
  reward, then the resulting 100 BTC should be considered 75% tainted).
  @p{»»}

  @p{««}RE: orphans: orphans happen naturally when two nodes on the network
  find blocks at approximately the same time. Somebody should do a
  rigorous analysis to determine what are the most important factors
  affecting orphan rates (number of connections? quality of connections?
  bandwidth available to "blast out" the new block? block size? Number of
  not-previously-seen transactions included in the block?) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2109}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-09-23 20:00:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=300102.msg3219725@s{hash}msg3219725
@section 3 {tx}

  @s{quotedtext}

  @p{««} We all think we're very clever at coming up with unique ways to
  obscure our data. @p{»»}

  @p{««}We are wrong. @p{»»}

  @p{««}We tend to think alike, so pretty much any process you can think up
  is likely very similar to a process somebody else will think up. @p{»»}

  @p{««}In short: humans are really bad at creating randomness (aka
  entropy). And we're even meta-bad, because we THINK we're good at it.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2110}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-01 00:33:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=303761.msg3273512@s{hash}msg3273512
@section 3 {tx}

  @s{quotedtext}

  @p{««} Relying on any single piece of hardware to secure your bitcoins is
  a bad idea. In the future, you should use two pieces of hardware created
  in two different parts of the world by two different organizations in
  two different legal jurisdictions to secure your bitcoins. @p{»»}

  @p{««}Right now... "only invest time or money you can afford to lose."
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2111}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-09 08:10:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=300809.msg3305064@s{hash}msg3305064
@section 3 {tx}

  @p{««}"Impress with this protocol" ?? @p{»»}

  @p{««}My primary motivation for the payment protocol can be seen in this
  mock-up of multi-signature transaction authorization: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}I want much more secure wallets, but we can't get there unless the
  "who am I paying" piece is authenticated. @p{»»}

  @p{««}You should save the "Gavin is trying to impress evil institutional
  investors" mud-slinging for when I get around to laying out the argument
  for increasing the block size, because that would be closer to the
  truth. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2112}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-16 03:32:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=310323.msg3346530@s{hash}msg3346530
@section 3 {tx}

  @p{««}Great idea! @p{»»}

  @p{««}If implemented, it would probably make sense to create a little
  protocol for the server and client to negotiate the amount of storage
  needed to "rent" a connection slot. Maybe the server reports something
  like "I've got 0 slots free, min/median/max proof-of-storage for my
  other connected nodes is 0/1MB/11MB." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2113}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-21 21:52:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=128442.msg3382702@s{hash}msg3382702
@section 3 {tx}

  @p{««}@p{(bf}@p{(it}@p{(big}SERIOUSLY, SHADOWOFHARBINGER:@p{big)}@p{it)}@p{bf)} @p{»»}

  @p{««}@p{(bf}@p{(it}@p{(big}I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING
  ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME
  WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND
  AGAIN!@p{big)}@p{it)}@p{bf)} 

# ----------------------------------------------------------------------
@section 2 {ms2114}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-24 02:30:27 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=144331.msg3399106@s{hash}msg3399106
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... then volunteer to run through @p{(link}the test plan@p{link)}
  and help shake out any bugs. Code that touches the wallet is
  particularly sensitive, because an obscure bug might cause lots of
  people to lose lots of money.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2115}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-26 05:30:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=313707.msg3413780@s{hash}msg3413780
@section 3 {tx}

  @p{««}If you're on OSX you can do this: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}I don't know if Windows or Linux have a similar way of adding
  metadata to arbitrary files. @p{»»}

  @p{««}PS: there will be (or maybe is, can't remember when the option was
  added) a -wallet=@p{lt}name@s{gt} option to open up a different .dat
  file for the wallet.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2116}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-26 05:33:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=317233.msg3413785@s{hash}msg3413785
@section 3 {tx}

  @p{««}Peter's dust-b-gone: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2117}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-27 23:44:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=131443.msg3424118@s{hash}msg3424118
@section 3 {tx}

  @p{««}Time-in-the-future transactions are non-standard (as of 0.8? I can
  never remember when things happened...) @p{»»}

  @p{««}Why: because there is a fill-up-memory denial of service attack,
  and it really isn't reasonable to expect the entire network to store
  your timelocked transactions "forever". @p{»»}

  @p{««}Even in the past, the statement "unspendable by the sender because
  of replacement not being implemented" was not true. Wait long enough and
  only a subset of the network will have the timelocked transaction
  (because new nodes, old nodes restarting, etc). Broadcast a
  double-spending version without a timelock and it will get mined fairly
  soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2118}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-29 22:43:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=321086.msg3438121@s{hash}msg3438121
@section 3 {tx}

  @s{quotedtext}

  @p{««} I don't follow. Where does the real-world wealth come from? What
  will those pull-up-by-their-own-bootstraps people be doing that makes
  the world a better place and makes them wealthier? @p{»»}

  @p{««}I suspect you might be confusing "money" with "wealth." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2119}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-30 07:06:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=293307.msg3440283@s{hash}msg3440283
@section 3 {tx}

  @s{quotedtext}

  @p{««} Good idea. I nominate you to be the Official Checksum Publishing
  Person.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2120}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-10-31 22:23:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=321086.msg3453043@s{hash}msg3453043
@section 3 {tx}

  @s{quotedtext}

  @p{««} If I am a good writer, why would I pay out 10% of my income? That
  is more expensive than credit card charges! @p{»»}

  @p{««}Again, don't confuse money for wealth. Writers produce wealth in
  the form of the stories/articles/whatever they are writing. The currency
  used to trade that wealth only matters as far as: @p{»»}

  @p{(li}  What can the writer buy with it  @p{li)}

    @p{(li}@p{(li} If the writer saves it, will it buy more or less in the
    future @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2121}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 00:05:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=321086.msg3453536@s{hash}msg3453536
@section 3 {tx}

  @p{««}I feel like we're talking past each other. @p{»»}

  @p{««}You said: dev coin is a good model@p{--} e.g. writer creates
  something, uses devcoin, 90% goes to them, 10% to devcoin miner. @p{»»}

  @p{««}I don't understand why a writer wouldn't just use dollars@p{--}
  create something, sell it for dollars, writer keeps 96%, PayPal gets 4%
  for processing the transaction. @p{»»}

  @p{««}Or Bitcoin: create something, sell it for Bitcoin, writer keeps 99%
  BitPay gets 1% for processing the transaction (Bitcoin can do this
  because it is more efficient than PayPal/credit card/traditional fiat,
  that is where the wealth is created). @p{»»}

  @p{««}Or is there some magical way that using an alt coin creates wealth
  out of thin air? I don't see it....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2122}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 10:17:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322748.msg3455719@s{hash}msg3455719
@section 3 {tx}

  @p{««}Consensus is the block size limit will have to rise. @p{»»}

  @p{««}Us geeks were/will/are arguing over how and when, not if... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2123}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 10:35:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322748.msg3455812@s{hash}msg3455812
@section 3 {tx}

  @p{««}See: @p{(link}Average block size chart@p{link)} @p{»»}

  @p{««}Since implementing the "dust rule", block size has been pretty
  steady; I would guess we won't hit the 1MB hard limit for another two
  years, but that is just a guess, we could easily hit it sooner or later
  than that. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2124}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 21:24:32
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322328.msg3459482@s{hash}msg3459482
@section 3 {tx}

  @s{quotedtext}

  @p{««} Exactly right, in my humble opinion. @p{»»}

  @p{««}I suspect you're going to have a hard time figuring out how to
  arrange yourselves without becoming a Corporation of some State and
  still have a business model that sustains sufficient quality assurance
  and customer support to make Dark Wallet a success. @p{»»}

  @p{««}PS: I'm really happy to see other implementations happening!
  Diversity is great! @p{»»}

  @p{««}PPS: y'all should give the Foundation at least a LITTLE bit of
  credit for funding CoinPunk... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2125}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 21:26:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322898.msg3459502@s{hash}msg3459502
@section 3 {tx}

  @p{««}Please don't say "official client" @p{--} there is no "official."
  @p{»»}

  @p{««}"Reference implementation" is more accurate. @p{»»}

  @p{««}Lack of SPV mode in the reference implementation is mostly due to
  lack of testing / code review resources. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2126}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 22:36:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=321086.msg3459887@s{hash}msg3459887
@section 3 {tx}

  @s{quotedtext}

  @p{««} Don't do that; spamming is evil. @p{»»}

  @p{««} RE: hyper-complexity of the multi-coin paradigm: @p{»»}

  @p{««}uhhh... Were you a postmodern lit major in college? @p{»»}

  @p{««} I've got a pretty simple, but I think fairly accurate, view of
  money/wealth. @p{»»}

  @p{««}I believe you can't create wealth just by printing money. You can
  create the illusion of wealth (and I imagine some Keynesians would argue
  the illusion is enough to lubricate the economy and somehow increase
  productivity and growth and wealth; lets set aside that argument). @p{»»}

  @p{««}You can create wealth by making it easier for people to transact
  (and money is the world's best invention for doing that, barter is
  terribly inefficient). @p{»»}

  @p{««}I'm still stuck on how y'all think altcoins create wealth. I don't
  see any of them being any easier to transact than Bitcoin. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2127}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-01 23:30:29
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322328.msg3460168@s{hash}msg3460168
@section 3 {tx}

  @p{««}RE: bitcoin-security mailing list: bottom line is I don't trust
  you. I think you have made irresponsible decisions in the past, and I
  don't trust that you would handle sensitive security issues responsibly.
  Happily there have been approximately zero cross-implementation security
  issues in the last six months, so it is more of a theoretical issue that
  you're not on the list.... @p{»»}

  @p{««}RE: foundation phone call: I personally agree that fundraising for
  a vaporware wallet is less newsworthy than a 9 million dollar reputable
  VC investment. @p{»»}

  @p{««}RE: libbitcoin: when there is significant software using it and it
  has been "battle tested" a bit I'd be happy to mention it. But last I
  heard even Intersango was not using it because it was too slow/immature.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2128}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-02 02:50:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322328.msg3461261@s{hash}msg3461261
@section 3 {tx}

  @s{quotedtext}

  @p{««} You're right, I apologize. I just added libbitcoin to that list.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2129}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-02 02:58:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=321086.msg3461308@s{hash}msg3461308
@section 3 {tx}

  @s{quotedtext}

  @p{««} Mmm. Maybe. @p{»»}

  @p{««}That sounds a lot like the alternative local currency
  movement@p{--} create a local currency that somehow expresses the local
  community's values. @p{»»}

  @p{««}I'm probably just a too-logical, cold-hearted geek, but building
  community around a currency doesn't strike a chord with me. To me,
  community is about people, and a currency is just a tool for
  transactions. I guess an analogy would be a bunch of carpenters who
  build a community around some Extra Special brand of nails that they
  create and trade amongst themselves. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2130}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-04 09:19:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=324527.msg3477451@s{hash}msg3477451
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. If their anonymous credential scheme is successful (and I hope
  it is!), then the payment protocol should be extended to use it. The
  payment protocol is quite carefully designed so that replacing the
  public key infrastructure system is easy. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2131}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-04 09:25:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=324413.msg3477481@s{hash}msg3477481
@section 3 {tx}

  @s{quotedtext}

  @p{««} No; miners have a natural incentive to want to be closely
  connected to as many other miners as possible (to reduce orphan costs).
  @p{»»}

  @p{««}RE: Evaluating sybil resistance: I would still like to see blocks
  and transactions being broadcast over another completely different
  networking protocol, either peer-to-peer or not. More diversity so we're
  not relying on the one p2p network would be great, and, depending on how
  it was implemented, might automatically bring sybil resistance. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2132}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-05 00:22:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=322748.msg3483936@s{hash}msg3483936
@section 3 {tx}

  @s{quotedtext}

  @p{««} Which "bitcoin client" ? @p{»»}

  @p{««}The client-side of Multibit and electrum should have no problem
  handling that transaction volume. Only the transactions relevant to your
  wallet are sent to your machine when you are running those clients.
  @p{»»}

  @p{««}The reference implementation can't handle that transaction volume
  today, but I 100% guarantee that version 11.11 which I 100% guarantee
  will be released on November 11'th, 2022 will be able to handle that
  transaction volume. @p{»»}

  @p{««}I feel obliged to insert my standard disclaimer: Bitcoin is an
  experiment in progress. Only invest time or money that you can afford to
  lose, there is still a chance the experiment may fail for some reason we
  don't forsee. Past results are no guarantee blah blah blah. @p{»»}

  @p{««}That said, I'm more confident than ever that the network will be
  able to scale up and remain decentralized. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2133}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-05 00:38:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=324972.msg3484040@s{hash}msg3484040
@section 3 {tx}

  @p{««}See: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @s{quotedtext}

  @p{««} You can calculate the "orphan cost" of including an extra
  1kilobyte of transactions in your block from that, which gives a floor
  on reasonable transaction fees. @p{»»}

  @p{««}RE: can we decrease that delay: sure, up to a point. But
  across-the-world network latency gives a physical limit. @p{brk} See,
  for example: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2134}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-06 04:53:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=324413.msg3495630@s{hash}msg3495630
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}This is the kind of analysis that I think we need more of before
  jumping to the conclusion that there is actually a problem that needs to
  be fixed. I'm not claiming that HorseRider is correct, but his logic
  looks plausible and I tend to listen harder to reasonable people who say
  things like "please check whether my logic is right". @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2135}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-07 21:51:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=327064.msg3513506@s{hash}msg3513506
@section 3 {tx}

  @p{««}I have several partly-formed thoughts. @p{»»}

  @p{««}First, on "is there REALLY a problem" @p{--} I think Ed Felten
  makes a good argument that, at least in the current world of mining
  pools, the incentives work to prevent "selfish" mining: @s{(link)} @p{»»}

  @p{««}Related, I think it is important to remember that the current
  structure and behavior of the p2p networking code is NOT part of the
  fundamental consensus algorithm. It is easy to change, and, as I've said
  in the past, I would really like to see blocks and transactions being
  broadcast over some completely different networking protocol. @p{»»}

  @p{««}I think there is a really interesting theoretical question that I
  don't know the answer to; I'll try to state it clearly: @p{»»}

  @p{««}As the p2p network is currently implemented, nodes only have a
  partial view of competing best-chains, because nodes only relay the
  first node they see at a given height. @p{»»}

  @p{««}If there are two blocks at the same height announced at
  approximately the same time, they propagate exponentially fast across
  the network in two waves, and only the nodes at the edges of where the
  waves meet will see both blocks. @p{»»}

  @p{««}Given that network behavior, assuming no selfish mining, there is a
  strong incentive to announce your block as soon as possible, because in
  an exponentially fast race any delay is very likely to make you lose.
  @p{»»}

  @p{««}There are lots of ideas for fixing selfish mining that rely on
  changing that behavior, and having nodes relay orphan blocks. I think it
  is important to remember that no matter what rules we SAY the network
  will follow, we can't stop individual nodes from implementing whatever
  rules they wish to follow; any solution that begins "If all nodes do
  THIS..." is not a solution. @p{»»}

  @p{««}That applies to the behavior we have now about not relaying orphan
  blocks, too, of course. The interesting theoretical question I'm
  pondering: does the security of the Bitcoin system depend on the
  relaying behavior, or on how ties are resolved in block races? @p{»»}

  @p{««}My intuition is that we SHOULD be relaying all orphan blocks, and
  should let each node decide how to resolve races, but before we talk
  about how to resolve races I think we should consider the incentives
  that arise from the current relaying behavior. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2136}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-07 22:42:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=326559.msg3513959@s{hash}msg3513959
@section 3 {tx}

  @p{««}Nice! Can you open source this? @p{»»}

  @p{««}Is the simulator accurately modeling how orphan blocks are (not)
  relayed? @p{»»}

  @p{««}It would also be useful to see total revenue, and
  total-revenue-expected-if-everybody-mines-honestly for both the entire
  network and the attacker. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2137}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-07 23:08:14
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=324972.msg3514227@s{hash}msg3514227
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. @p{»»}

  @p{««}I am much more worried about transaction fees right now than
  "selfish mining". That is why I've been working on better fee estimation
  in the reference implementation. @p{»»}

  @p{««}I agree with Mike@p{--} we need better measurement, and we need to
  make "full-match merkle block relaying" the default to drive that 80ms
  number way down.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2138}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-12 10:09:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=331104.msg3557125@s{hash}msg3557125
@section 3 {tx}

  @p{««}A surprising number of people will trade @p{(it}anything@p{it)}
  that has a price.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2139}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-12 10:18:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=151430.msg3557169@s{hash}msg3557169
@section 3 {tx}

  @p{««}Unconfirmed wallet transactions @p{(bf}are@p{bf)} automatically
  rebroadcast by bitcoind/Bitcoin-QT until they are confirmed.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2140}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-12 23:32:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=327064.msg3563866@s{hash}msg3563866
@section 3 {tx}

  @p{««}By the way: @p{»»}

  @p{««}I really like your proposal, ByteCoin. I think it captures the
  intuitive notion of "incentivize publishing blocks immediately as the
  best policy". @p{»»}

  @p{««}IF all proof-of-work-valid chains are relayed (and, as I said, my
  intuition is that they should be) then
  highest-number-of-transactionseconds seems like a very good criteria for
  resolving ties. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2141}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-14 02:10:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=333236.msg3575963@s{hash}msg3575963
@section 3 {tx}

  @s{quotedtext}

  @p{««} No. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2142}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-20 03:17:05
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=339802.msg3646998@s{hash}msg3646998
@section 3 {tx}

  @s{quotedtext}

  @p{««} Transaction fees are likely to go up (in dollar terms) for a
  while, until some engineering work is done to reduce the "orphan cost"
  for miners to include more transactions in their blocks @p{(bf}OR@p{bf)}
  mining pools / miners collectively agree to include more transactions
  for the good of the whole system. @p{»»}

  @p{««}In the very short term, you can ask mining pool operators to create
  larger blocks. If they refuse, then switch your miners to a pool that
  does. @p{»»}

  @p{««}If they all create larger blocks, then we get more transactions and
  more orphan blocks, but the cost of those extra orphan blocks is spread
  across everybody mining, so everybody gets just as many bitcoins (on
  average) as they would with smaller blocks. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2143}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-20 06:42:38
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=339505.msg3648359@s{hash}msg3648359
@section 3 {tx}

  @p{««}DeathAndTaxes: I'm normally impressed with your posts, but I think
  you've got some details wrong. @p{»»}

  @p{««}First, RE: the orphan cost of transactions:
  @p{(link}Decker/Wattenhofer measured@p{link)} 80ms for a 1K bigger
  block. The math to compute orphan cost is: @p{»»}

  @s{code}

  @p{««}Plugging in 25 XBT block reward, 600 target time, 0.08 delta time,
  and assuming no fees (to make the math easier): @p{»»}

  @s{code}

  @p{««}So 3.3 millies per kilobyte is the orphan cost. @p{»»}

  @p{««}Even if we assume Decker/Wattenhofer are off by a factor of two (we
  @p{(bf}have@p{bf)} made some improvements since they measured block
  propagation; better measurements welcome), @p{(so}default transaction
  fees (1 to 5 millies per kilobyte) are in the right ballpark to minimize
  orphan costs.@p{so)} the .1 default transaction fee does not come close
  to covering the orphan cost (edited: thanks foxpup). @p{»»}

  @p{««}It should be fairly easy to get about another factor of about 10-20
  reduction in orphan costs. And as I said in another thread, if EVERYBODY
  produces larger blocks then EVERYBODY bears the increased orphan cost,
  and the result is better for everybody . There is a fixed number of new
  bitcoins to be earned, regardless of the orphan rate; everybody's share
  of that fixed number will be the same if everybody has a slightly higher
  orphan block rate. But everybody will earn more fees, and their bitcoins
  will be worth more because bitcoins will be more useful.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2144}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-20 08:20:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=339505.msg3648939@s{hash}msg3648939
@section 3 {tx}

  @p{««}Yes, I did misplace the decimal point. I'm really good at
  that.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2145}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-22 00:57:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=338452.msg3669700@s{hash}msg3669700
@section 3 {tx}

  @p{««}It looks like maybe some pools have reacted; the average block size
  is going up: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}For those that haven't, the relevant bitcoind command-line
  arguments are: @p{»»}

    @p{(li}-blockminsize=@p{lt}n@s{gt} Set minimum block size in bytes
    (default: 0) @p{li)}

    @p{(li}-blockmaxsize=@p{lt}n@s{gt} Set maximum block size in bytes
    (default: 250000) @p{li)}

    @p{(li}-blockprioritysize=@p{lt}n@s{gt} Set maximum size of
    high-priority/low-fee transactions in bytes (default: 27000) @p{li)}

    @p{(li}-mintxfee=@p{lt}m.n@s{gt} Minimum fee-per-kilobyte to qualify
    as fee-paying (default: 0.0001) @p{li)}

  @p{««} Adding: @p{»»}

  @s{code}

  @p{««}... to your bitcoin.conf and re-starting bitcoind (or running with
  the command-line arguments) will really help with the transaction
  crunch. @p{»»}

  @p{««}I'm still hard at work (nearly done!) on making the reference
  implementation much smarter about transaction fees, but until wallet
  software gets smarter about fees we need to rely on big pools doing the
  right thing so Bitcoin users don't get frustrated by long transaction
  confirmation times. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2146}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-11-26 02:09:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=346877.msg3715585@s{hash}msg3715585
@section 3 {tx}

  @p{««}You disgust me. Participating in a ponzi is immoral. @p{»»}

  @p{««}You might as well ask "Anybody know some good scams I can make
  money from?" @p{»»}

  @p{««}Do something productive that makes the world a better place
  instead.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2147}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-12-04 03:47:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=356408.msg3815449@s{hash}msg3815449
@section 3 {tx}

  @p{««}@s{(link)} sketches out one way to do it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2148}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2013-12-09 20:36:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=364353.msg3895848@s{hash}msg3895848
@section 3 {tx}

  @p{««}Bah, I forgot to code-sign the Windows .exe. Expect an updated .exe
  and SHASUMS soon.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2149}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-01-12 22:12:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412846.msg4473814@s{hash}msg4473814
@section 3 {tx}

  @p{««}I've accepted an invitation to do a question and answer session at
  the @p{(link}Council on Foreign Relations (CFR)@p{link)} in Washington,
  DC on Thursday, February 6, 2014. @p{»»}

  @p{««}I've been told anything related to the Council on Foreign Relations
  tickle's peoples Grand Conspiracy buttons, so I thought it would be best
  to be open about exactly what will happen. I hope it doesn't spark as
  long a thread as my visit to the CIA, but Bitcoin is a lot bigger than
  when I visited the CIA... @p{»»}

  @p{««}Anyway, here's the invitation I received: @p{»»}

  @s{quotedtext}

  @p{««} The format of the event will be a 90-minute question&amp;answer
  session, moderated by somebody yet-to-be-determined. It will be "on the
  record," meaning press could be invited to attend and recordings and/or
  transcripts may be posted on CFR's website. @p{»»}

  @p{««}The audience will be CFR members and invited guests (and maybe
  press); it is not open to the public. I am not getting paid by the CFR.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2150}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-01-13 21:16:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412530.msg4493088@s{hash}msg4493088
@section 3 {tx}

  @p{««}No, not possible, given what we know about the properties of SHA256
  hashing. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2151}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-01-13 23:54:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412846.msg4495813@s{hash}msg4495813
@section 3 {tx}

  @s{quotedtext}

  @p{««} Bilderberger meetup is in Barbados this year. But don't tell
  anybody, it is a secret. @p{»»}

  @p{««} PS to dewdeded: Mike Hearn and I both own non-US passports, so
  putting us on Team USA is funny. We should be Team Global Conspiracy
  (mmm... gotta get T-shirts made...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2152}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-01-14 02:20:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412846.msg4497754@s{hash}msg4497754
@section 3 {tx}

  @p{««}I'm usually pretty careful not to call people names. Did I screw
  up? @p{»»}

  @p{««}I DO think there are lots of crazy conspiracy theories. I might
  even believe some of them myself, but that doesn't make me crazy (just
  "almost certainly wrong."). @p{»»}

  @p{««}RE: child exploitation: Good example. We all agree that child
  exploitation is BAD, right? @p{»»}

  @p{««}We might disagree about what (if anything) we should DO about it,
  but isn't it worth discussing whether or not there is something we MIGHT
  do about it? For example, maybe offering mostly-anonymous bounties to
  reward anybody who gives information that leads to the arrest and
  conviction of people abusing children for profit or pleasure is a good
  idea. Maybe those bounties could be paid in Bitcoin. @p{»»}

  @p{««}Maybe that is a terrible idea that will have awful consequences,
  but instead of rational discussion there's a knee-jerk GOVERNMENT BAD!
  that, in my humble opinion, is counter-productive to making the world a
  better place. @p{»»}

  @p{««}I don't like people assuming that they know what I'm thinking, or
  assume that because I'm willing to talk to people that I agree with
  those people, or assume that because I'm pragmatic about regulation I
  "want regulation." For the record: I'm mostly libertarian, I think we'd
  be just fine if we replaced 99.911% of regulations with voluntary,
  private, market-based solutions. But that ain't gonna happen any time
  soon. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2153}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-02-01 22:11:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=431513.msg4882293@s{hash}msg4882293
@section 3 {tx}

  @p{««}How do transaction fees work in Ethereum? @p{»»}

  @p{««}One of the non-obvious reasons Bitcoin works is transaction fees
  are based on the size (in bytes) of the transaction. And since there are
  no loops executing a transaction, CPU usage is bound by transaction
  size. @p{»»}

  @p{««}If CPU usage to verify a transaction is NOT related to the
  transaction size, then you open yourself up to denial-of-service
  attacks. Like: @p{»»}

  @p{««}Create an Ethereum transaction with a (huge!) fee that will pay for
  60 seconds of CPU execution time. @p{brk} ... but craft it so execution
  takes 61 seconds (or, heck, make it an infinite loop, maybe you'll
  tickle a bug in the execution termination code). @p{»»}

  @p{««}Now broadcast it. It will be rejected for insufficient fee, but
  @p{(it}only after peers have wasted 60 seconds of CPU time@p{it)}. And
  if the transaction is rejected, the attacker won't pay the fee. @p{»»}

  @p{««}Then tweak it slightly and broadcast it again, maybe from a
  different IP address if you got banned for bad behavior. @p{»»}

  @p{««} @p{hrule} I haven't thought deeply about whether or not there is a
  way to punish the attacker; my first thought would be to publish the
  attacker's transaction and take the fee but ignore any other effects of
  the transaction, but you'd have to be careful to design THAT mechanism
  so it couldn't be abused. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2154}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-02-02 17:10:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=431513.msg4896407@s{hash}msg4896407
@section 3 {tx}

  @p{««}Okey dokey... so how do fees work in Ethereum? @p{»»}

  @p{««}Or do you have some other clever distributed way of preventing
  flood-the-system-with-bogus-contracts DoS attacks? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2155}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-02-03 13:11:18
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=431513.msg4910989@s{hash}msg4910989
@section 3 {tx}

  @p{««}Thanks, k99 and Vitalik, that helps clear it up. I've put "On
  Transaction Fees, And The Fallacy of Market-Based Solutions" on my
  to-think-about-deeply list. @p{»»}

  @p{««}I'm curious about this, though: @p{»»}

  @s{quotedtext}

  @p{««} If my contract needs more than 16 computational steps to execute,
  then other people CAN send transactions to it to intentionally bankrupt
  it? That is what I was worrying about when I said "publish the
  attacker's transaction and take the fee but ignore any other effects of
  the transaction, but you'd have to be careful to design THAT mechanism
  so it couldn't be abused." @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2156}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-03-19 20:55:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=522014.msg5791032@s{hash}msg5791032
@section 3 {tx}

  @s{quotedtext}

  @p{««} This was a release process bug; I re-built/signed/uploaded the OSX
  .dmg to fix it (and updated the SHASUMS files). @p{»»}

  @p{««}The warning is harmless, and no code was changed, so if you don't
  want to re-download and install you don't have to. @p{»»}

  @p{««}Thanks to lots of hard work from Luke Dashjr and Cory Fields we
  should (fingers crossed!) have deterministic OSX builds working before
  the next release, which will make this kind of error impossible. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2157}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-03-24 13:04:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=528768.msg5872434@s{hash}msg5872434
@section 3 {tx}

  @p{««}Sounds familiar... @p{»»}

  @p{««}... I think I ran into a similar problem that turned out to be ssh
  being upset that the file permissions on the id_dsa file used to login
  to the virtual machine were too permissive (because I was running from a
  FAT32-formatted USB stick that didn't support file permissions at all,
  if I recall correctly, which I probably don't). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2158}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-04-03 15:30:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=551513.msg6053842@s{hash}msg6053842
@section 3 {tx}

  @s{quotedtext}

  @p{««} For low-priority transactions, it doesn't look to me like many
  miners are accepting lower fees. @p{»»}

  @p{««}Right now, a 999-byte transaction paying the
  reference-implementation-default fee of 0.0001 BTC will wait 2-3 hours
  to get into a block. @p{»»}

  @p{««}A typical 250-byte transaction paying the default 0.0001 BTC fee
  will see its first confirmation in 5 or 6 blocks (about an hour on
  average). If you want your transaction to confirm quickly, then right
  now you need to pay about double the default fee. @p{»»}

  @p{««}Some results running @s{(link)} (more review/testing welcome) :
  @p{»»}

   @s{code}

# ----------------------------------------------------------------------
@section 2 {ms2159}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-04-10 21:37:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=563048.msg6163077@s{hash}msg6163077
@section 3 {tx}

  @p{««}@s{(link)} is a little SSL server to test SSL clients for
  heartbleed vulnerability. @p{»»}

  @p{««}I installed Bitcoin Core version 0.9.0 on my Mac (compiled against
  the vulnerable openssl 1.0.1f), created a web page to launch a payment
  request fetch from pacemaker... @p{»»}

  @p{««}... and I get good news: @p{»»}

  @p{««}Code: Connection from: 127.0.0.1:62937 @p{brk} Possibly not
  vulnerable @p{»»}

  @p{««} Step-by-step so you can help test on other OS'es : @p{»»}

    @s{code}

  @p{««} In your browser, visit @s{(link)} @p{»»}

  @p{««}pacemaker.py should report a connection, and then either say
  "Client returned blah bytes" or "Possibly not vulnerable" @p{»»}

  @p{««}It looks to me like pacemaker.py IS working; visiting @s{(link)} in
  Chrome pacemaker tells me: @p{»»}

  @s{code}

  @p{««} This isn't a definitive "no need to worry even if you HAVE clicked
  on payment-protocol-enabled bitcoin: links at an untrustworthy website"
  ... but given the evidence I've seen, it seems to me extremely unlikely
  anybody's private keys have been compromised. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2160}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-04-11 16:12:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=563048.msg6174364@s{hash}msg6174364
@section 3 {tx}

  @p{««}On further testing, it looks like OSX and Linux payment protocol
  requests with the released 0.9.0 binaries are not vulnerable. @p{»»}

  @p{««}The released Windows 0.9.0 binaries are vulnerable, so Wladimir
  just sent an alert message urging everybody running 0.9.0 to upgrade.
  @p{»»}

  @s{quotedtext}

  @p{««}Check again; see the use of CKeyingMaterial/CPrivKey which uses a
  secure_allocator (which asks the operating system not to swap the memory
  to disk, and which zeros memory on free). If I recall correctly, the RPC
  importprivkey should be the only place where the normal memory allocator
  is used (the keys exist as ordinary hex strings in memory before they
  are processed by the importprivkey code). @p{»»}

  @p{««}Careful review (and testing and patches) is always welcome, of
  course. You shouldn't trust my famously faulty memory. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2161}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-04-13 16:36:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=567937.msg6200377@s{hash}msg6200377
@section 3 {tx}

  @s{quotedtext}

  @p{««} There is a lot of competition for the free transaction area in
  blocks these days; you need a much higher priority to get confirmed
  quickly, 57.6 million is not enough any more. @p{»»}

  @p{««}A future version of the reference implementation wallet will
  automatically estimate the priority needed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2162}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-04-13 16:43:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=567321.msg6200458@s{hash}msg6200458
@section 3 {tx}

  @p{««}transactions send via sendrawtransaction are always debited from
  the default "" account. Raw transactions and accounts are not designed
  to work together, use one or the other . @p{»»}

  @p{««}And preferably not accounts: unless somebody steps up and
  volunteers to make the accounts feature "industrial-strength" (scalable,
  integrates with whatever back-end database your company is using to
  track user information, can be robustly backed up, etc) it is very
  likely it will be deprecated and then dropped. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2163}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-05-25 14:55:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=623344.msg6930909@s{hash}msg6930909
@section 3 {tx}

  @s{quotedtext}

  @p{««} Feel free to create some; code here: @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms2164}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-05-30 00:42:25 
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=631056.msg7025989@s{hash}msg7025989
@section 3 {tx}

  @s{quotedtext}

  @p{««} The Bitcoin Foundation @p{(bf}does@p{bf)} help pay for dev
  efforts; it pays me, Wladimir, and Cory Fields (and gives quarterly
  grants to fund other worthwhile efforts). @p{»»}

  @p{««}I disagree with the original poster; Bitcoin development is
  increasingly decentralized over time. It started out as centralized as
  it could possibly be@p{--} Satoshi wrote all the code himself (or
  herself or their-selves). @p{»»}

  @p{««}Now we have multiple implementations, multiple altcoins, and
  multiple wanna-be-Bitcoin-2.0 contenders, all with their own dev
  person-or-team (well, some altcoins probably don't have any developers).
  @p{»»}

  @p{««}As for your specific ideas: go for it. If you think they're good
  ideas, implement them (or hire or convince somebody to implement them)
  and see what happens. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2165}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-05-30 17:44:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=76073.msg7040808@s{hash}msg7040808
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'll break my "don't feed the trolls" rule: @p{»»}

  @p{««}You need two things to get private bitcoin transactions: @p{»»}

  @p{««}1) An anonymous connection to the Internet. Bitcoin Core does a
  good job of this, working nicely through Tor and/or as a hidden service
  (thanks to Pieter Wuille for writing that code). @p{»»}

  @p{««}2) A privacy-aware wallet. @p{»»}

  @p{««}The Bitcoin Core wallet needs to be completely rewritten, not just
  for privacy but to get rid of the Berkeley DB dependency, implement HD
  keys, implement multisig, CoinJoin, etc etc etc.... @p{»»}

  @p{««}Nobody has stepped up to do that, so it hasn't happened; in fact,
  we are going in the opposite direction, moving wallet functionality out
  of Core (and we might eventually drop wallet functionality entirely to
  concentrate on transaction validation and blockchain handling). @p{»»}

  @p{««}Why do you ask? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2166}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-01 20:17:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635317.msg7078514@s{hash}msg7078514
@section 3 {tx}

  @p{««}In another thread marcus of augustus says: @p{»»}

  @s{quotedtext}

  @p{««} I'll break my rule about feeding trolls again to debunk for about
  the hundredth time the myth that the use of X.509 certificates in the
  payment protocol is bad for privacy. @p{»»}

  @p{««}It is not. @p{»»}

  @p{««}If you are in a customer/merchant situation, the customer's privacy
  is not affected AT ALL. The merchant's identity is in the X.509
  certificate, the customer is as anonymous as always (which is very often
  "not anonymous", because the merchant needs to know something about the
  customer to deliver their product). @p{»»}

  @p{««}If you are a merchant, then part of the PURPOSE of the payment
  protocol is to provide a cryptographically secure, verified-in-some-way
  identity. @p{»»}

  @p{««}If you are a merchant and want an pseudanonymous then that is easy:
  set up an anonymous email address and then get a free email certificate
  from any of the certificate authorities that provide them. @p{»»}

  @p{««}If you have a philosophical hatred of X.509 and certificate
  authorities... then please invent a better identity verification system
  and get the world to adopt it. The payment protocol is specifically
  designed to make it easy to slide in a better system. @p{»»}

  @p{««}(but if you have a philosophical hatred of X.509 then what are you
  doing posting here at bitcointalk, whose security relies on the very
  X.509 certificates you find so despicable? There ARE alternatives, you
  should go hang out in forums.i2p or a Tor-based forum...) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2167}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-01 23:04:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635344.msg7080875@s{hash}msg7080875
@section 3 {tx}

  @p{««}Login as ubuntu, password "ubuntu" @p{»»}

  @p{««}I think, if I remember correctly. @p{»»}

  @p{««}Wait... no, maybe not. According to the README there, you need to
  ssh in using the private key in the ssh_key.tar file. That super long
  "password" is not a password, but is the ssh public key.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2168}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-01 23:10:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635383.msg7080952@s{hash}msg7080952
@section 3 {tx}

  @p{««}See @s{(link)} and @s{(link)} @p{»»}

  @p{««}A future release will automagically figure out the right fee (or
  will figure out it doesn't need a fee) to get into a block quickly (or
  slowly, if you want to pay lower fees and are willing to wait). @p{»»}

  @p{««}As for your original question: set the -paytxfee command-line
  option for current Core releases and you WILL always pay a fee.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2169}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-02 14:56:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635317.msg7090818@s{hash}msg7090818
@section 3 {tx}

  @s{quotedtext}

  @p{««} You are going back on my ignore list, because you have no idea
  what you are talking about. @p{»»}

  @p{««}Maybe if I use simple, easy-to-follow steps I can convince you that
  you are wrong: @p{»»}

    @p{(li} 1. Copy and paste this URL into your web browser: @p{li)}

    @p{(li}@s{(link)} @p{li)}

    @p{(li} 2. Click on the "Free email certificate: sign up now" button
    (the big orange one). @p{li)}

    @p{(li} 3. Enter whatever name you like, and a valid email address (an
    anonymous one, if you like) and a revocation password. @p{li)}

  @p{««}I just used "@p{(link}knownothingtroll@s{at}mailinator.com@p{link)}" to
  make sure it actually does work to give a fake name, anonymous email
  address (and no address or phone number). @p{»»}

  @p{««}Done deal, you've now got a certificate-authority-signed X.509
  certificate for an anonymous email address that you can use for the
  payment protocol. @p{»»}

  @p{««}That wasn't so hard, was it? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2170}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-02 15:54:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635317.msg7091802@s{hash}msg7091802
@section 3 {tx}

  @s{quotedtext}

  @p{««} That is like 9/11 conspiracy theorists saying "there is a real
  debate to be had!" ... after they repeatedly fail to listen to rational
  arguments ("Jet Fuel doesn't burn that hot! It cannot melt steel!" ...
  after being patiently told about the physics of furnaces: burning in a
  heat-trapping chamber). @p{»»}

  @p{««}I still haven't heard any rational arguments on how the payment
  protocol is worse for privacy. If piotr_n makes one, please let me know.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2171}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-02 16:01:51
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=635383.msg7091921@s{hash}msg7091921
@section 3 {tx}

  @s{quotedtext}

  @p{««} The hard-coded setting for "high priority" is just wrong (it is
  much too low for the number of free transactions competing to be
  included in blocks these days). The "smart fees" pull request fixes
  that, and will (by default) only send a transaction for free if it is
  pretty darn sure it will confirm quickly. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2172}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-09 16:55:25
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=644189.msg7216413@s{hash}msg7216413
@section 3 {tx}

  @p{««}New 'estimatefee' and 'estimatepriority' RPC commands were just
  pulled into Bitcoin Core. @p{»»}

  @p{««}And I threw up a web page that updates estimates with every new
  block found: @s{(link)} @p{»»}

  @p{««}Assuming I got the crontab correct, daily fee/priority estimates
  will be archived there starting tomorrow. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2173}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-14 15:46:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=645852.msg7309365@s{hash}msg7309365
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes. I think most people believe that successful technology
  companies spring up very quickly, but in my experience most (all?) of
  the "overnight successes" were busy working for years before finding the
  winning combination of features, user interface, market, etc. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2174}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-16 15:18:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=609411.msg7344745@s{hash}msg7344745
@section 3 {tx}

  @p{««}I haven't been paying to the whole "cloud hashing" thing, but it
  seems to me a great cover for an old-fashioned Ponzi scheme. @p{»»}

    @p{(li} 1. Take investors BTC, "buy" gigahashes of mining. @p{li)}

    @p{(li} 2. Pay them back for a while using new investor's BTC. @p{li)}


    @p{(li} 3. Once you've got enough investors, take the BTC and run.
    (maybe claim "oops, sorry, got hacked") @p{li)}

  @p{««}I'm not saying CEX.IO is a tarted-up Ponzi scheme. I have no idea.
  @p{»»}

  @p{««}I'm just asking how everybody who is giving them money knows that
  they aren't a Ponzi. Or aren't selling the same hardware twice or three
  times, operating a kind of 'fractional reserve' system (that will
  eventually fall apart). @p{»»}

  @p{««}Excuse me in advance if this has been discussed and I'm just
  missing something (e.g. a variation on Greg Maxwell's exchange auditing
  scheme might work: e.g. "they publish all the blocks found and an
  auditable merkle tree of all customers and how much hashing power each
  has"). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2175}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-24 18:22:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=632124.msg7493562@s{hash}msg7493562
@section 3 {tx}

  @s{quotedtext}

  @p{««} Excellent! @p{»»}

  @p{««}I've been accused in the past of "not caring about privacy" @p{--}
  when I do care a lot about privacy. But I am not a privacy researcher,
  and I have a deep respect for how difficult it is to create a truly
  privacy-preserving system. @p{»»}

  @p{««}I'm very happy that somebody who @p{(bf}is@p{bf)} an expert is
  thinking about, and working on, countermeasures. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2176}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-06-27 16:42:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=668044.msg7549766@s{hash}msg7549766
@section 3 {tx}

  @p{««}The best way to understand reference implementation accounts is to
  think of bitcoins like real, physical coins. @p{»»}

  @p{««}Like how a bank works: @p{»»}

  @p{««}When you deposit coins in your account, they are credited to your
  account. And then mixed in with all the other coins the bank gets.
  @p{brk} When you withdraw, you get coins from the Big Old Pool of
  Coins@p{--} not the coins you put in, necessarily. @p{»»}

  @p{««}That said: general consensus among core devs is that the accounts
  feature should go away. It is not appropriate for "enterprise-scale"
  multi-user use (never optimized for that case, doesn't do ACID
  transactions with whatever back-end database you're using for customer
  information, etc etc etc). @p{»»}

  @p{««}And it doesn't do what most people seem to WANT it to do (act as
  multiple wallets, keeping coins separate). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2177}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-07-03 14:56:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=673415.msg7658481@s{hash}msg7658481
@section 3 {tx}

  @p{««}It seems to me having miners share 'near-miss' blocks with each
  other (and the rest of the world) does several good things. @p{»»}

  @p{««}As Greg say, that tells you how much hashing power is including
  your not-yet-confirmed transaction, which should let merchants reason
  better about the risk of their transactions being double-spent. @p{»»}

  @p{««}If the protocol is well-designed, sharing near-miss blocks should
  also make propagation of complete blocks almost instantaneous most of
  the time. All of the data in the block (except the nonce and the
  coinbase) is likely to have already been validated/propagated. See
  Greg's thoughts on efficient encoding of blocks: @s{(link)} @p{»»}

  @p{««}So there could almost always be no advantage to working on a
  smaller block rather than a larger block (it would be very rare to find
  a full-difficulty block before finding@p{--} say@p{--} a 1/100'th
  difficulty block). @p{»»}

  @p{««}Near-instant block propagation if you 'show your work' should give
  un-selfish miners an advantage over miners who try any kind of block
  withholding attack. And it should make network convergence quicker in
  the case of block races; miners could estimate how much hashing power is
  working on each fork when there are two competing forks on the network,
  and rational miners will abandon what looks like a losing fork as soon
  as it looks statistically likely (based on the previous-block pointers
  for near-miss blocks they see) that they're on the losing fork. @p{»»}

  @p{««}We can do all of this without a hard fork. It could even be
  prototyped as an ultra-efficient "miner backbone network" separate from
  the existing p2p network@p{--} in fact, I'm thinking it SHOULD be done
  first as a separate network... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2178}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-07-04 00:07:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=669243.msg7666002@s{hash}msg7666002
@section 3 {tx}

  @p{««}Smart (dynamic, floating) fees for the reference implementation
  wallet was pulled today: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... and should appear in version 0.10. @p{»»}

  @p{««}The estimation code only considers transactions that are broadcast
  on the network, enter the memory pool (so are available to any miner to
  mine), and then are included in a block. So it is immune to miners
  putting pay-to-self transactions with artificially high fees in their
  blocks. @p{»»}

  @p{««}Right now if you use the default fee rules your transactions will
  take 2-6 blocks to confirm: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}The priority estimation code is even more broken; the reference
  implementation wallet will send a 56-million-priority transaction with
  no fee, which is nowhere near enough priority to get confirmed quickly:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}(the smart fee code estimates priority, too). @p{»»}

  @p{««}Release notes from doc/release-notes.md in the source tree: @p{»»}

  @p{««}Transaction fee changes @p{»»}

  @p{««}This release automatically estimates how high a transaction fee (or
  how @p{brk} high a priority) transactions require to be confirmed
  quickly. The default @p{brk} settings will create transactions that
  confirm quickly; see the new @p{brk} 'txconfirmtarget' setting to
  control the tradeoff between fees and @p{brk} confirmation times. @p{»»}

  @p{««}Prior releases used hard-coded fees (and priorities), and would
  @p{brk} sometimes create transactions that took a very long time to
  confirm. @p{»»}

  @p{««} New Command Line Options @p{»»}

  @p{««}-txconfirmtarget=n : create transactions that have enough fees (or
  priority) so they are likely to confirm within n blocks (default: 1).
  This setting is over-ridden by the -paytxfee option. @p{»»}

  @p{««}New RPC methods @p{»»}

  @p{««}Fee/Priority estimation@p{»»}

  @p{««}estimatefee nblocks : Returns approximate fee-per-1,000-bytes
  needed for a transaction to be confirmed within nblocks. Returns -1 if
  not enough transactions have been observed to compute a good estimate.
  @p{»»}

  @p{««}estimatepriority nblocks : Returns approximate priority needed for
  a zero-fee transaction to confirm within nblocks. Returns -1 if not
  enough free transactions have been observed to compute a good estimate.
  @p{»»}

  @p{««}Statistics used to estimate fees and priorities are saved in the
  data directory in the 'fee_estimates.dat' file just before program
  shutdown, and are read in at startup. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2179}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-07-04 17:09:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=669243.msg7676870@s{hash}msg7676870
@section 3 {tx}

  @s{quotedtext}

  @p{««} ... demonstrated in a completely artificial -regtest
  environment... @p{»»}

  @p{««}If you can Sybil somebody and control their view of the network,
  then it seems to me there are more potentially profitable attacks than
  "make them pay more in fees than they should." @p{»»}

  @p{««}But please feel free to demonstrate an actual, effective Sybil on
  the fee estimation code. bitcoincore.org is running a wallet-less
  bitcoind on port 8333 that generates the graphs at
  bitcoincore.org/smartfee/ @p{»»}

  @p{««}(hacking into the web server to make it LOOK like the fee
  estimation code failed doesn't count, you have to manage to control it's
  p2p network connections and then manipulate the memory pool). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2180}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-07-09 17:57:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=669243.msg7756249@s{hash}msg7756249
@section 3 {tx}

  @s{quotedtext}

  @p{««} That is exactly what the 'smartfee' code in the reference
  implementation does. @p{»»}

  @p{««}RE: where does the market information come from: @p{»»}

  @p{««}Like any market, it comes from the collective action of lots of
  individual decisions. Different wallet software has different fee
  policies, and there is already a little bit of "I sent a transaction
  using wallet XYZ and it took FOREVER to confirm, WTF?!?" (or "why does
  exchange/wallet/service ABC charge me such high transaction fees").
  @p{»»}

  @p{««}As wallets mature, I expect them to specialize ("Save on Fees! Use
  UberWallet!") and/or compete for best
  cost/speed/reliability/predictability. @p{»»}

  @p{««}The default for the reference implementation will be "follow the
  herd" @p{--} but the price will be set by the minority of people 'at the
  margins' who REALLY want their transactions to confirm quickly or REALLY
  want spend as little as possible on transaction fees. They will set
  -paytxfee and/or -txconfirmtarget to override the default behavior.
  @p{»»}

  @p{««}And "they" are likely to be high-volume-transaction-creators@p{--}
  like exchanges (probably want their transactions to confirm quickly;
  fewer customer support calls) or watch-a-video-get-a-few-bits services
  (probably want to cut costs any way they can, don't care if their
  customers have to wait a while for a withdrawal to get confirmed...).
  @p{»»}

  @p{««}RE: sybil/isolation attack: @p{»»}

  @p{««}Again, not a likely attack. You would have to: @p{brk}

    @p{(li} 1) Find some high-transaction-volume service and identify all
    of their bitcoin-network-connected nodes @p{li)}

    @p{(li} 2) Control ALL of those nodes' connections (expensive to do
    reliably with the 'connect out to 8 random peers' rule) FROM THE
    BEGINNING OF TIME (well, beginning of when it started running the
    smartfee code). @p{li)}

    @p{(li} 3) Let that node see only extremely-high-fee transactions
    (there aren't very many of those, so you'll need to manage to control
    the node's connections for a while). @p{li)}

    @p{(li} 4) Expect the node's operator to send a lot of transactions
    and not notice that they were paying abnormally high transaction fees.
    @p{li)}

  @p{««}If you are running a high-transaction-volume service you probably
  already have several connections into the bitcoin p2p network because
  you have probably already been the target of a distributed denial of
  service attack.... @p{»»}

  @p{««}Definitely not an issue for Bitcoin-Qt, because you're shown the
  total amount + fees you'll pay before every transaction. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2181}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-08-12 14:21:03
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=734360.msg8313237@s{hash}msg8313237
@section 3 {tx}

  @p{««}Block re-orgs need some thought. @p{»»}

  @p{««}If I have chain A-B-C, and get IBLT's for an alternative chain
  A-B'-C'-D'... @p{»»}

  @p{««}... then the current memory pool won't work to try to reconstruct
  B' C' D'. @p{»»}

  @p{««}Using B and C to reconstruct B' and C' should work pretty well.
  Then the remaining memory pool transactions can be used to reconstruct
  D. @p{»»}

  @p{««}If any of the reconstructions fail, just fall back to fetching all
  of B' C' D'. @p{»»}

  @p{««}Then again, re-orgs are rare enough that always falling back to
  fetching full blocks would be OK. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2182}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-08-13 00:16:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=731949.msg8322036@s{hash}msg8322036
@section 3 {tx}

  @p{««}It is absolutely true! I heard the main guy even visited the NSA's
  headquarters in Fort Langley, Maryland! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2183}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-08-21 14:27:35
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=709970.msg8469901@s{hash}msg8469901
@section 3 {tx}

  @s{quotedtext}

  @p{««} Glancing at @p{(link}block explorers for Monero and
  ByteCoin@p{link)}... I'm not seeing crippling bloat right now. I see
  lots of very-few-transactions blocks. @p{»»}

  @p{««}Glancing at recent @p{(link}release notes for ByteCoin@p{link)}, it
  looks like transactions were not being prioritized by fee, which is a
  fundamental to getting a working fee market. @p{»»}

  @p{««}Have Monero and ByteCoin fixed the bloat problem, or did the
  transaction spammers just get bored and go away? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2184}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-09 16:41:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=315802.msg8747447@s{hash}msg8747447
@section 3 {tx}

  @p{««}I think we're seeing some people submitting lots of tiny, trivial
  commits @p{--} perhaps because they get more of the tipping pie. @p{»»}

  @p{««}I'm not sure how to combat that bad incentive.... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2185}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-10 16:51:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=776541.msg8763548@s{hash}msg8763548
@section 3 {tx}

  @p{««}Thaddeus Dryja's "proof of idle" idea hasn't been getting enough
  attention. See @s{(link)} @p{»»}

  @p{««}The idea is to get paid NOT to mine, because it is economically
  rational for everybody to keep the difficulty lower rather than higher
  (everybody saves money on electricity if everybody can somehow agree to
  keep their equipment idle). Thaddeus figured out a way of solving the
  coordination problem so nobody can lie about how much mining power they
  have or profit from cheating and running miners that they promised to
  keep idle. @p{»»}

  @p{««}Having lots of idle mining capacity is appealing for at least two
  reasons @p{--} it is more energy efficient, and if an attack of some
  kind is detected it could be brought online instead of kept idle to help
  fight the attack. @p{»»}


  @p{hrule}

  @p{««}However... I suspect that taking that idle mining power, pointing
  it to a big mining pool, and then performing a
  winning-share-withholding-attack (if you find a share that satisfies
  full network difficulty, don't submit it to the pool @p{--} just throw
  it away and pretend it never happened) could be a way of doubling your
  profits, because you drive down difficulty, get paid for "idle"
  capacity, AND get a share of the profits from the mining pool you're
  attacking. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2186}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-15 12:29:24
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=779941.msg8828500@s{hash}msg8828500
@section 3 {tx}

  @p{««}I needed that, so hacked together a disconnectpeer RPC call: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}Needs more thorough testing@p{--} I'm not sure if calling
  CloseSocketDisconnect directly from the RPC thread is the cleanest way
  of disconnecting a peer. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2187}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-17 15:11:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=786145.msg8860902@s{hash}msg8860902
@section 3 {tx}

  @p{««}Probably just some anti-Foundation skiddie who saw this: @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2188}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-17 15:23:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=770591.msg8861070@s{hash}msg8861070
@section 3 {tx}

  @p{««}Is there a rebuttal from the PoS crowd to this: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}... other than "sure, the original PoS ideas were flawed, but the
  latest MegaUberPoS system gets it right and nobody has figured out
  exactly how to break it!" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2189}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-09-17 15:56:49
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=770591.msg8861478@s{hash}msg8861478
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think we'll see non-clone coins being broken after two things
  happen: @p{»»}

    @p{(li} 1. They become valuable enough for attackers to bother, and
    there is some way for them to cash out. @p{li)}

    @p{(li} 2. The attackers have some time to do what they need to do to
    mount an attack@p{--} write code, deploy botnets, hack into some big
    exchange(s), get their hands on some early-adopter's wallet backups,
    or whatever. @p{li)}

  @p{««}Once the tools and techniques are developed, then I think we'll see
  what we see in PoW 51% attacks: attacks against even mostly-worthless
  clonecoins, because if they've already got the tools then they might
  just attack for the lulz. @p{»»}

  @p{««}I'm surprised you count peercoin a PoS success@p{--} they're still
  running with centralized checkpoints, aren't they? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2190}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-04 17:00:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=807131.msg9080898@s{hash}msg9080898
@section 3 {tx}

  @s{quotedtext}

  @p{««} That @p{(bf}is@p{bf)} a feature of Bitcoin-Qt. Unconfirmed dust
  transactions don't enter the memory pool, so they are not relayed, not
  included in blocks being mined, and not displayed by the wallet. @p{»»}

  @p{««}If I recall correctly, if they DO get mined into a block by
  somebody then they are displayed. Ignoring them and not adding them to
  the wallet in that case might be a nice feature, although today's dust
  might be tomorrow's treasure if prices rise another couple orders of
  magnitude.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2191}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-06 18:25:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=813324.msg9106557@s{hash}msg9106557
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, that is what I am saying. @p{»»}

  @p{««}"Safer" : there are two competing threats here: raise the block
  size too slowly and you discourage transactions and increase their
  price. The danger is Bitcoin becomes irrelevant for anything besides
  huge transactions, and is used only by big corporations and is too
  expensive for individuals. Hurray, we just reinvented the SWIFT or ACH
  systems. @p{»»}

  @p{««}Raise it too quickly and it gets too expensive for ordinary people
  to run full nodes. @p{»»}

  @p{««}So I'm saying: the future is uncertain, but there is a clear trend.
  Lets follow that trend, because it is the best predictor of what will
  happen that we have. @p{»»}

  @p{««}If the experts are wrong, and bandwidth growth (or CPU growth or
  memory growth or whatever) slows or stops in ten years, then fine:
  change the largest-block-I'll-accept formula. Lowering the maximum is
  easier than raising it (lowering is a soft-forking change that would
  only affect stubborn miners who insisted on creating
  larger-than-what-the-majority-wants blocks). @p{»»}

  @p{««} RE: a quick fix like doubling the size: @p{»»}

  @p{««}Why doubling? Please don't be lazy, at least do some
  back-of-the-envelope calculations to justify your numbers (to save you
  some work: the average Bitcoin transaction is about 250 bytes big). The
  typical broadband home internet connection can support much larger
  blocks today. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2192}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-08 17:36:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=813324.msg9131431@s{hash}msg9131431
@section 3 {tx}

  @s{quotedtext}

  @p{««} When I say "soft-fork" I mean "a majority of miners upgrade and
  force all the rest of the miners to go along (but merchants and other
  fully-validating, non-mining nodes do not have to upgrade)." @p{»»}

  @p{««}Note that individual miners (or sub-majority cartels) can
  unilaterally create smaller blocks containing just higher-fee
  transactions, if they think it is in their long-term interest to put
  upward pressure on transaction fees. @p{»»}

  @s{quotedtext}

  @p{««} Would 40% initial size and growth make you support the proposal?
  @p{»»}

  @s{quotedtext}

  @p{««} Anybody know economists who specialize in this sort of problem?
  Judging by what I know about economics and economists, I suspect if we
  ask eleven of them we'll get seven different opinions for the best thing
  to do. Five of which will miss the point of Bitcoin entirely. ("...elect
  a Board of Blocksize Governors that decides on an Optimal Size based on
  market supply and demand conditions as measured by an independent Bureau
  of Blocksize Research....") @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2193}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-09 19:51:30
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=813324.msg9145004@s{hash}msg9145004
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm working on a follow-up blog post that talks about economics of
  the block size, but want to get it reviewed by some real economists to
  make sure my thinking is reasonably correct. But I'm curious: why do you
  think an extremely large block size will mess up the economics of
  mining? What do you think would happen? @p{»»}

  @p{««}RE: geometric growth cannot go on forever: true, but Moore's law
  has been going steady for 40 years now. The most pessimistic prediction
  I could find said it would last at least another 10-20 years; the most
  optimistic, 600 years. @p{»»}

  @p{««}I'd be happy with "increase block size 40% per year (double every
  two years) for 20 years, then stop." @p{»»}

  @p{««}Because if Bitcoin is going gangbusters 15 years from now, and CPU
  and bandwidth growth is still going strong, then either the "X%" or the
  "then stop date" can be changed to continue growing. @p{»»}

  @p{««}I did some research, and the average "good" broadband Internet
  connection in the US is 10Mbps speed. But ISPs are putting caps on home
  users' total bandwidth usage per month, typically 250 or 300GB/month. If
  I recall correctly, 300GB per month was the limit for my ISP in
  Australia, too. @p{»»}

  @p{««}Do the math, and 40% of a 250GB connection works out to 21MB
  dedicated to Bitcoin every ten minutes. Leave a generous megabyte for
  overhead, that would work out to a starting point of maximum-size-20MB
  blocks. @p{»»}

  @p{««}(somebody check my math, I'm really good at dropping zeroes) @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2194}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-09 22:14:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=813324.msg9146609@s{hash}msg9146609
@section 3 {tx}

  @s{quotedtext}

  @p{««} Thanks for checking my math! I used 31-day months, since I assume
  that is how ISPs do the bandwidth cap. @p{»»}

  @p{««}RE: what happens with Tor: @p{»»}

  @p{««}Run a full node (or better, several full nodes) that is connected
  to the network directly@p{--} not via Tor. @p{»»}

  @p{««}But to keep your transactions private, you broadcast them through a
  Tor-connected SPV (not full) node. If you are mining, broadcast new
  blocks the same way. @p{»»}

  @p{««}That gives you fully-validating-node security plus
  transaction/block privacy. You could run both the full node and the
  SPV-Tor-connected node on a machine at home; to the rest of the network
  your home IP address would look like a relay node that never generated
  any transactions or blocks. @p{»»}

  @p{««}If you live in a country where even just connecting to the Bitcoin
  network is illegal (or would draw unwelcome attention to yourself), then
  you'd need to pay for a server somewhere else and administer it via
  Tor.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2195}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-13 19:05:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9188675@s{hash}msg9188675
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'm sending a follow-up blog post to a couple of economists to
  review, to make sure my economic reasoning is correct, but I don't
  believe that even an infinite blocksize would drive fees to zero
  forever. @p{»»}

  @p{««}Commodity prices never drop to zero, no matter how abundant they
  are (assuming a reasonably free market@p{--} government can, of course
  supply "free" goods, but the results are never pretty). The suppliers of
  the commodities have to make a profit, or they'll find something else to
  do. @p{»»}

  @p{««}That has very little to do with whether or not transaction fees
  will be enough to secure the network in the future. I think both the
  "DON'T RAISE BLOCKSIZE OR THE WORLD WILL END!" and "MUST RAISE THE
  BLOCKSIZE OR THE WORLD WILL END!" factions confuse those two issues. I
  don't think adjusting the block size up or down or keeping it the same
  will have any effect on whether or not transaction fees will be enough
  to secure the network as the block subsidy goes to zero (and, as I said,
  I'll ask professional economists what they think). @p{»»}

  @s{quotedtext}

  @p{««} Okey dokey. You can join the people still mining on
  we-prefer-50-BTC-per-block fork (if you can find them... I think they
  gave up really quickly after the 50 to 25 BTC subsidy decrease). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2196}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-14 15:11:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9198596@s{hash}msg9198596
@section 3 {tx}

  @s{quotedtext}

  @p{««} That does not address the core of people's fears, which is that
  big, centralized mining concerns will collaborate to push smaller
  competitors off the network by driving up the median block size. @p{»»}

  @s{quotedtext}

  @p{««} Yes, that is a good point, made by other people in the other
  thread about this. A more conservative rule would be fine with me, e.g.
  @p{»»}

  @p{««}Fact: average "good" home Internet connection is 250GB/month
  bandwidth. @p{brk} Fact: Internet bandwidth has been growing at 50% per
  year for the last 20 years. @p{»»}

    @p{(li}(if you can find better data than me on these, please post
    links). @p{li)}

  @p{««}So I propose the maximum block size be increased to 20MB as soon as
  we can be sure the reference implementation code can handle blocks that
  large (that works out to about 40% of 250GB per month). @p{brk} Increase
  the maximum by 40% every two years (really, double every two years@p{--}
  thanks to whoever pointed out 40% per year is 96% over two years)
  @p{brk} Since nothing can grow forever, stop doubling after 20 years.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2197}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-14 15:47:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=329634.msg9198983@s{hash}msg9198983
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, today. But not at some point in the future. Please read about
  "UTXO commitments" in @s{(link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2198}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-14 22:07:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9203315@s{hash}msg9203315
@section 3 {tx}

  @s{quotedtext}

  @p{««} Because network bandwidth, CPU, main memory, and disk storage (the
  potential bottlenecks) are all growing exponentially right now, and are
  projected to continue growing exponentially for the next couple decades.
  @p{»»}

  @p{««}Why would we choose linear growth when the trend is exponential
  growth? @p{»»}

  @p{««}Unless you think we should artificially limit Bitcoin itself to
  linear growth for some reason. Exponential growth in number of users and
  usage is what we want, yes? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2199}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-14 22:12:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=813324.msg9203347@s{hash}msg9203347
@section 3 {tx}

  @s{quotedtext}

  @p{««} The fear is that a cartel of big, centralized,
  have-huge-data-pipes miners would drive out smaller miners by forcing up
  the block size high enough so the smaller miners have to drop out. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2200}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-15 18:34:45
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9213761@s{hash}msg9213761
@section 3 {tx}

  @s{quotedtext}

  @p{««} Okey dokey. My latest straw-man proposal is 40% per year growth
  for 20 years. That seems like a reasonable compromise based on current
  conditions and trends. @p{»»}

  @p{««}You seem to be looking hard for reasons not to grow the block
  size@p{--} for example, yes, CPU clock speed growth has stopped. But
  number of cores put onto a chip continues to grow, so Moore's Law
  continues. (and the reference implementation already uses as many cores
  as you have to validate transactions) @p{»»}

  @p{««}PS: I got positive feedback from a couple of full-time,
  professional economists on my "block size economics" post, it should be
  up tomorrow or Friday. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2201}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-16 21:50:58
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9227819@s{hash}msg9227819
@section 3 {tx}

  @s{quotedtext}

  @p{««}Pure coincidence, but I had lunch today with a local developer who
  will be putting up a building in downtown Amherst. They are planning on
  running fiber to the building, because they want to build for the future
  and the people they want to sell to (like me in a few years, when we
  downsize after my kids are in college) want fast Internet. @p{»»}

  @p{««}If I gaze into my crystal ball... I see nothing but more and more
  demand for bandwidth. @p{»»}

  @p{««}We've got streaming Netflix now, at "pretty good" quality. We'll
  want enough bandwidth to stream retina-display-quality to every family
  member in the house simultaneously. @p{»»}

  @p{««}Then we'll want to stream HD 3D surround video to our Oculus Rift
  gizmos, which is probably another order of magnitude in bandwidth. To
  every member of the family, simultaneously. While our home security
  cameras stream to some security center off-site that is storing it as
  potential evidence in case of burglary or vandalism.... @p{»»}

  @p{««}Then... who knows? Every prediction of "@p{(it}this@p{it)} will
  surely be enough technology" has turned out to be wrong so far. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2202}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-17 16:02:17
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9235606@s{hash}msg9235606
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you're reinventing Matt's fast block relay code. See:
  @p{»»}

    @p{(li}@s{(link)} @p{li)}

# ----------------------------------------------------------------------
@section 2 {ms2203}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-17 16:14:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=822100.msg9235731@s{hash}msg9235731
@section 3 {tx}

  @p{««}I'm confused. In the lottery example: @p{»»}

  @s{quotedtext}

  @p{««}What is the timestamp for a transaction? When the node receiving
  the transaction receives it? The timestamp of the block in which the
  transaction is confirmed? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2204}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-17 16:15:33
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9235744@s{hash}msg9235744
@section 3 {tx}

  @s{quotedtext}

  @p{««} It is already being done, so yes. Optimizations to how
  transactions or blocks are communicated between peers don't require any
  sort of fork.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2205}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-17 16:48:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=822100.msg9236129@s{hash}msg9236129
@section 3 {tx}

  @s{quotedtext}

  @p{««} Uhhh.... okey dokey. That sounds really dangerous, because it
  means a blockchain re-org can change the meaning or behavior of a
  transaction. "There Be Dragons" @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2206}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-17 16:55:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=799967.msg9236226@s{hash}msg9236226
@section 3 {tx}

  @s{quotedtext}

  @p{««}If you're using the GUI: File-@s{gt}Backup Wallet... @p{»»}

  @p{««}If you're using bitcoind: use the backupwallet RPC command. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2207}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-18 15:16:46
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9245730@s{hash}msg9245730
@section 3 {tx}

  @s{quotedtext}

  @p{««} The answer cannot be in the blockchain, because the problem being
  addressed (resource usage rising too quickly so only people willing to
  spend tens of thousands of dollars can participate as fully validating
  nodes) is outside the blockchain. @p{»»}

  @p{««}You will go down the same path as the proof-of-stake folks, coming
  up with ever more complicated on-blockchain solutions to a problem that
  fundamentally involves something that is happening outside the
  blockchain. In this case, real-world CPU and bandwidth growth. In the
  POS case, proof that some kind of real-world effort was performed. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2208}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-19 14:39:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9254595@s{hash}msg9254595
@section 3 {tx}

  @s{quotedtext}

  @p{««} I am trying to get consensus. The process will look like: @p{»»}

  @p{««}Get rough consensus. I need to write some code to find out what
  size blocks the current code can handle, but other than that I think
  we're close to rough consensus on the approach. @p{»»}

  @p{««}Note: Getting consensus that we actually need to change something
  NOW will be harder; it will be much easier to get consensus after we hit
  the 1MB blocksize limit and transaction fees spike up. It would be
  lovely to avoid that panic/pain. @p{»»}

  @p{««}Implement the change / Write a BIP (these happen at about the same
  time). @p{»»}

  @p{««}Submit a pull request, after code is reviewed pull it into the
  reference implementation. @p{»»}

  @p{««}... wait until there is a release containing the change... @p{»»}

  @p{««}... wait until supermajority of miners have upgraded to the new
  release... @p{»»}

  @p{««}Voila, the possibility of bigger blocks.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2209}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-19 14:49:09
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9254666@s{hash}msg9254666
@section 3 {tx}

  @s{quotedtext}

  @p{««} Did you read my "blocksize economics" blog post? @p{»»}

  @p{««}I don't understand why you think MAX_BLOCK_SIZE necessarily has
  anything to do with "supporting mining" (aka securing the network).
  @p{»»}

  @p{««}What stops this from happening: @p{»»}

  @p{««}Big miners accept off-blockchain payments from big merchants and
  exchanges that want their transactions confirmed. They are included in
  very small blocks with zero fees. The blocksize stays at 1MB forever.
  @p{»»}

  @p{««}Lets look at incentives: @p{»»}

  @p{««}Big miners: have cozy agreements with Big Merchants. Those
  agreements keep the little guys out. @p{»»}

  @p{««}Big Merchants: same thing. The need to get an agreement with a
  miner to get your transactions accepted is a barrier to entry for the
  Little Guys.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2210}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-19 14:57:26
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9254725@s{hash}msg9254725
@section 3 {tx}

  @s{quotedtext}

  @p{««} Is there really any disagreement? Everybody I have talked with
  believes that transaction fees will rise if Bitcoin is successful and
  the 1MB limit is kept. @p{»»}

  @p{««}How much we won't know@p{--} that depends on how much demand for
  transactions moves somewhere else (fiat currency, altcoin, or some
  off-blockchain solution). @p{»»}

  @p{««}There is a small minority of people who believe that it would be
  BETTER if transactions moved to fiat currency, an altcoin, or some
  more-centralized off-blockchain solution. I strongly disagree. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2211}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-20 13:22:21
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9264484@s{hash}msg9264484
@section 3 {tx}

  @s{quotedtext}

  @p{««} Please stop trolling. I think what I think and do what I do
  because I want the Bitcoin Project to be even more wildly successful.
  @p{»»}

  @p{««}If I was motivated by greed I would have a much higher salary. And
  lots of stock options. @p{»»}

  @p{««}The majority of Bitcoin users here want transaction fees less than
  a penny; I want them to be as low as practical. The only way to get
  there is to increase the block size. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2212}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-23 13:50:34
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9302698@s{hash}msg9302698
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think you are confusing MAX_BLOCKSIZE with the floating,
  whatever-the market-demands blocksize. @p{»»}

  @p{««}MAX_BLOCKSIZE is, in my mind, purely a safety valve@p{--} a "just
  in case" upper limit to make sure it doesn't grow faster than affordable
  hardware and software can support. @p{»»}

  @p{««}Ideally, we never bump into it. If we go with my proposal (increase
  to 20MB now, then double ten times over the next twenty years) I think
  it is reasonably likely the market-determined size will never bump into
  MAX_BLOCKSIZE. @p{»»}

  @p{««}I think it is very unlikely that in 20 years we will need to
  support more Bitcoin transactions than all of the cash, credit card and
  international wire transactions that happen in the world today (and that
  is the scale of transactions that a pretty-good year-2035 home computer
  and network connection should be able to support). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2213}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-23 14:20:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9303005@s{hash}msg9303005
@section 3 {tx}

  @s{quotedtext}

  @p{««} When you respond to me saying patronizing things like "there are
  other problems with the way scalability is limited," I have trouble not
  thinking you are either confused or insane. Or just lazy, and did not
  read my "Scalability Roadmap" blog post. @p{»»}

  @p{««}It is certainly true that nobody can predict the future with 100%
  accuracy. We might get hit by an asteroid before I finish this sentence.
  (whew! didn't!) @p{»»}

  @p{««}But extrapolating current trends seems to me to be the best we can
  do@p{--} we are just as likely to be too conservative as too aggressive
  in our assumptions.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2214}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-23 14:30:20
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=815712.msg9303120@s{hash}msg9303120
@section 3 {tx}

  @s{quotedtext}

  @p{««} Start a new thread. HAVE you read my Scalability Roadmap blog
  post?@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2215}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-27 13:27:22
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=734360.msg9345736@s{hash}msg9345736
@section 3 {tx}

  @p{««}RE: O(1) versus O(some-function-of-total-number-of-transactions):
  @p{»»}

  @p{««}Yes, it will depend on whether or not the number of differences
  goes up as the number of transactions goes up. @p{»»}

  @p{««}The incentives align so it is in everybody's best interest to make
  the differences as small as possible. I wouldn't be surprised if that
  causes innovations to drive the actual size to O(1) minus an increasing
  constant, as code gets better at predicting which transactions our peers
  do or don't have. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2216}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-27 13:41:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9345865@s{hash}msg9345865
@section 3 {tx}

  @s{quotedtext}

  @p{««} "Huge stashes" is a bad assumption. Tweet from Jeff Garzik earlier
  this year: @p{»»}

    @p{(li}"As such, I dare to do what few if any others do: My @s{hash}bitcoin
    balance is 348.006 BTC." @p{li)}

  @p{««}I'm guessing other frequent contributors have this mindset: @p{»»}

  @s{quotedtext}

  @p{««} And I'm sure lots of early adopters thought: @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms2217}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-28 14:39:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9357473@s{hash}msg9357473
@section 3 {tx}

  @s{quotedtext}

  @p{««} I still feel that way. @p{»»}

  @p{««}I believe that if people want a secure network, they will figure
  out a way of getting it. My justification is the same as my belief that
  if people want clean, cheap, safe drinking water they will figure out a
  way of getting it. @p{»»}

  @p{««}I don't claim to know @p{(bf}how@p{bf)}, and it is very possible
  the @p{(bf}how@p{bf)} will offend the sensibilities of either (or both)
  of the "PRIVACY AT ANY COST!!!!" or "DECENTRALIZATION AT ANY COST!!!!"
  factions. Just like government regulations and institutions around clean
  water offend the "INDIVIDUAL LIBERTY AT ANY COST!!!!" faction. @p{»»}

  @p{««}I can imagine a lot of possible futures, from big merchants and
  exchanges investing in mining to save themselves on transaction fees and
  ensure that their transactions are confirmed securely, to assurance
  contracts, to a cartel of miners regulated and funded and licensed as a
  global public utility. @p{»»}

  @p{««}I hope that last one doesn't happen... @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2218}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-28 15:15:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9357899@s{hash}msg9357899
@section 3 {tx}

  @s{quotedtext}

  @p{««} That is easy, the first. But that is a straw-man argument. @p{»»}

  @p{««}If the decision is: costs 1.001 kWh and gives 99.99, versus 1kWh
  and gives 99%, I might decide the extra purity is worth it. @p{»»}

  @p{««}The "centralized is more efficient" might be theoretically true,
  but in practice the difference might be so slight it doesn't matter.
  @p{»»}

  @p{««}Theoretically, it would be more efficient if @p{(bf}all@p{bf)} of
  our computing happened in huge data centers located near cheap
  hydroelectric power. @p{»»}

  @p{««}Practically, though, only some of our computing happens that way
  (e.g. searching terabytes of data), because it is more convenient for us
  to carry around powerful little computers and we value that convenience.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2219}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-28 15:24:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=831868.msg9358009@s{hash}msg9358009
@section 3 {tx}

  @p{««}You can mitigate the attacks described in the paper by running
  bitcoind with more lenient banning behavior. @p{»»}

  @p{««}E.g. put this in your bitcoin.conf: @p{»»}

   @s{code}

  @p{««} ... so if Tor peers sharing an IP address are banned, they are
  only banned for eleven seconds. @p{»»}

  @p{««}If you want to live dangerously, you can also set: @p{»»}

   @s{code}

  @p{««} ... to make it a lot harder for an attacker to cause you to ban
  naughty IP addresses. But this might make it easier for an attacker to
  fill up your node's memory with garbage. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2220}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-10-28 15:53:19
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9358289@s{hash}msg9358289
@section 3 {tx}

  @s{quotedtext}

  @p{««} You seem to have a very narrow definition of "decentralized
  system." @p{»»}

  @p{««}In the future I imagine nodes might probabilistically check a
  random subset of transactions, and broadcast "this transaction is
  fraudulent" if they find anything wrong. If you imagine a million nodes,
  each fully validating one-in-ten-thousand transactions then you get each
  transaction validated on average 100 times. @p{»»}

  @p{««}That's not so different from your 'treechains' idea (just simpler
  and easier to reason about, in my humble opinion). @p{»»}

  @p{««}If you think that hardware costs are going to dominate
  decentralized-versus-centralized payment network costs, then I think
  you're wrong. Hardware is cheap, people are expensive. @p{»»}

  @p{««}But all of this is really arguing
  angels-dancing-on-the-heads-of-pins; we've got years before we have to
  worry about how to fund network security, and a whole lot of things to
  work on before then. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2221}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-01 23:30:31
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9408094@s{hash}msg9408094
@section 3 {tx}

  @s{quotedtext}

  @p{««} How do you imagine you will be able to keep transaction fees
  artificially high? @p{»»}

  @p{««}I can imagine a future with 1MB blocks full of zero-transaction-fee
  transactions (all fees paid off-blockchain through special cozy
  relationships between big merchants/exchanges and big miners. Or simply
  big merchants/exchanges mining their own transactions). @p{»»}

  @p{««}I think network security CAN be funded through transaction
  fees@p{--} that is easy, if you want to buy some security just attach a
  larger-than-strictly-necessary-to-get-confirmed fee to your
  transactions. @p{»»}

  @p{««}I don't think we know yet whether network security WILL be funded
  through transaction fees; there might be a free-rider problem that keeps
  people who @p{(bf}want@p{bf)} a secure network from actually
  @p{(bf}paying@p{bf)} for a secure network. @p{»»}

  @p{««}This is where it would be lovely for some academic economists who
  have studied the free-rider problem to chime in and predict what is
  likely to happen, and how other markets have solved (or not) the
  problem. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2222}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-01 23:59:08
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=822100.msg9408286@s{hash}msg9408286
@section 3 {tx}

  @s{quotedtext}

  @p{««} This is a very important concept to internalize. I don't think
  Satoshi realized it, and I think if he did Bitcoin Script would be very
  different from what we have. @p{»»}

  @p{««}In a future ideal world where arbitrary zero-knowledge-proofs are
  time-tested and have robust implementations, everybody except for the N
  entities directly involved in a transaction would validate a short,
  opaque proof that some computation took place authorizing the
  transaction. @p{»»}

  @p{««}If you're designing a better transaction system, you should design
  with that ideal in mind. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2223}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-02 13:55:55
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9412701@s{hash}msg9412701
@section 3 {tx}

  @p{««}I couldn't resist peeking at the literature; the first hit on a
  google search for "experimental economics free rider" turns up
  @p{(link}this 1984 paper:@p{link)} @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms2224}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-03 20:55:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=843842.msg9427534@s{hash}msg9427534
@section 3 {tx}

  @s{quotedtext}

  @p{««} "patches welcome" @p{»»}

  @p{««}In general: "meh" @p{--} most testing is done in -regtest mode in a
  more controlled environment these days. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2225}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-04 14:45:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=845955.msg9435120@s{hash}msg9435120
@section 3 {tx}

  @s{quotedtext}

  @p{««} YES THAT WAS TOTALLY AND COMPLEETLY A COINCEDENCE!!!! HE WUZ
  PLANNING ON LEAVING WAY BEFORE THAT! @p{»»}

  @p{««}I THINK THE OP IS RIGHT, SO I'M GONNA MOVE THE SOURCE CODE TO
  SUMPLACE MORE SECURE WHERE THE GOVERNMENT CAN'T SEE IT ANYMORE. AND I
  WENT AND GOT ME A GOOD HAT TO WEAR WHEN I WRITE CODE SO THEIR SATELITES
  CANT HEAR ME EITHER. @p{»»}

  @p{««}FOR THE CHILDREN! @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2226}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-04 14:50:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=831053.msg9435175@s{hash}msg9435175
@section 3 {tx}

  @s{quotedtext}

  @p{««} I'd also slightly prefer 'mikes', but consensus is for 'bits'
  among the people who will actually Make This So (the big
  merchants/exchanges). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2227}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-10 18:26:48
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=845955.msg9499718@s{hash}msg9499718
@section 3 {tx}

  @s{quotedtext}

  @p{««} Or maybe I just ate too much peyote one night (and, happily,
  decided to read bitcointalk instead of write some code). @p{»»}

  @p{««}(and for the humor-impaired: NO, NOT SERIOUS. Everybody knows I
  don't eat peyote, I spend my money on @p{(link}hookers and
  blow@p{link)}.)@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2228}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-12 18:34:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9522635@s{hash}msg9522635
@section 3 {tx}

  @s{quotedtext}

  @p{««} You are wrong. @p{»»}

  @p{««}Example that should make it clear: @p{»»}

  @p{««}Honest miner with 50% hash power: will mine 6 blocks every two
  hours (on average). Rest of the network will mine the other 6 blocks.
  @p{»»}

  @p{««}Attacking miner with 50% hash power: will mine 6 blocks every four
  hours (on average), because they refuse to build on anybody else's
  blocks. @p{»»}

  @p{««}Result: if the attacker is the longest chain, they'll get half as
  many BTC as honest mining (if they are unlucky and are not the longest
  chain, they'll get zero). @p{»»}

  @p{««}If they could keep up the attack for a full month until difficulty
  adjusts then they'll start making what they would have been making if
  they were honest.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2229}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-13 00:23:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=176684.msg9526235@s{hash}msg9526235
@section 3 {tx}

  @s{quotedtext}

  @p{««} Wait... no... that example is only valid for the "attacker takes
  over existing mining pools" case, where formerly honest miners are
  co-opted to be evil (or gang up in a cartel to be evil). @p{»»}

  @p{««}If somebody collects as much hashing power as the rest of the
  network combined and @p{(it}then@p{it)} suddenly attacks, then yes,
  indeed, difficulty stays the same, the attacker gets all the mining
  rewards, and there are twice as many stale blocks as before. Attacker
  gets 6 block rewards per hour. @p{»»}

  @p{««}If they were to mine honestly, blocks would be created twice as
  fast until difficulty adjusted, so they'd get 6 block rewards per hour
  for a week (same as if they decide to attack). Then difficulty would
  double, and they'd get only 3 per hour.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2230}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-16 19:32:36
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=858854.msg9563190@s{hash}msg9563190
@section 3 {tx}

  @p{««}See @s{(link)} 

# ----------------------------------------------------------------------
@section 2 {ms2231}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-16 19:41:37
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816612.msg9563267@s{hash}msg9563267
@section 3 {tx}

  @s{quotedtext}

  @p{««} Please be more precise. @p{»»}

  @p{««}Nobody "increases the block size" @p{--} miners choose to create
  larger or smaller blocks, up to the maximum block size limit. @p{»»}

  @p{««}And quoting myself: (from @p{(link}my recent blog post@p{link)}):
  @p{»»}

  @s{quotedtext}

# ----------------------------------------------------------------------
@section 2 {ms2232}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-17 16:59:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9571791@s{hash}msg9571791
@section 3 {tx}

  @s{quotedtext}

  @p{««} There seem to be a few people who want some OTHER algorithm for
  increasing the block size, but I'm hearing very broad consensus that we
  do need a hard fork to increase the size. @p{»»}

  @p{««}That is progress. @p{»»}

  @p{««}I'll be running some experiments using actual blockchain data to
  see where the current code breaks; if it can already handle 20MB blocks
  then I'll work through the details to propose a hard fork (write BIPs,
  write code, write tests, ...). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2233}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-17 18:09:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=816298.msg9572599@s{hash}msg9572599
@section 3 {tx}

  @s{quotedtext}

  @p{««} You don't seem to have the "jump in and help" mentality needed to
  participate in a radically open project like Bitcoin. @p{»»}

  @p{««}As I have said repeatedly in the past: you don't have to ask
  anybody for permission or advice. You are part of the process@p{--} make
  it happen. @p{»»}

  @p{««}Personally, I don't know nuthin about "opfor teams" ... (but am the
  creator of the Bitcoin testnet, so am offended by you saying there is no
  ability or desire to bring more testing rigor to Bitcoin).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2234}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-11-20 20:45:23
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=734360.msg9606123@s{hash}msg9606123
@section 3 {tx}

  @p{««}If you want to work on IBLT stuff... @p{»»}

  @p{««}... start with Matt's fast-relay code: @s{(link)} @p{»»}

  @p{««}That is an "I know what I've already told my peers, so I won't tell
  them again" optimization for transaction data. I haven't tried to figure
  out how far that already-written-and-running code lets us scale, but I
  think that would be the first step. @p{»»}

  @p{««}Once you understand what Matt is doing, then figure out how an IBLT
  can further optimize to eliminate sending even lists of transaction IDs.
  The first step there is to figure out what software miners are using to
  build their blocks, and figuring out how hard it would be to get that
  software to do the IBLT thing (have similar policies for selecting
  transactions, and identical policies for ordering transactions inside
  the block). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2235}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-12-03 13:45:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=881304.msg9727670@s{hash}msg9727670
@section 3 {tx}

  @p{««}Excellent advice. @p{»»}

  @p{««}I'd add: you never have infinite time, so you will have to
  prioritize. @p{»»}

  @p{««}Cryddit's original post talks a fair bit about preventing data
  leakage in side-channel attacks; I'll just say that if you only have
  time to either get 100% code path unit test coverage or hand-code some
  assembly to workaround your compiler leaving a private key in memory
  instead of a register... I'd work on the test coverage. @p{»»}

  @p{««}And if the choice is between 100% test coverage versus 91% with
  support for threshold signatures on multiple devices@p{--} I'd choose
  threshold signatures. @p{»»}

  @p{««}And, of course, the highest priority is creating a product or
  service that is both trustworthy and that people want to use. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2236}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-12-10 20:03:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=888727.msg9800154@s{hash}msg9800154
@section 3 {tx}

  @s{quotedtext}

  @p{««} I am not a lawyer, but... @p{brk} ... the money transmission laws
  and regulations are written very broadly. They almost certainly apply
  even if you are exchanging one crypto-currency for another, and no "real
  money" is involved. @p{»»}

  @p{««}The only saving grace is that the laws only apply if you are
  operating "a business" @p{--} so occasional lowish-value
  person-to-person exchanges done as a favor to friends at no markup from
  the current exchange rate is probably perfectly legal. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2237}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-12-12 20:41:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=412846.msg9821595@s{hash}msg9821595
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh what? Field report from my talk at the CFR? @p{»»}

  @p{««}I barely remember it, there were probably 50 people in suits in the
  audience, nobody I recognized. The whole thing is on video, there were
  no secret meetings, I got there 10 minutes before my talk and left 10
  minutes after (I had a bunch of interviews with DC-based journalists
  scheduled... and I think that was the trip I had lunch with Jim Harper
  and got a tour of Cato, although I might be mis-remembering). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2238}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2014-12-29 21:38:52
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=903782.msg9978192@s{hash}msg9978192
@section 3 {tx}

  @p{««}RE: can't wrap your head around what the Bitcoin Foundation does:
  @p{»»}

  @p{««}It is in big letters at the new @s{(link)} home page: @p{»»}

  @s{quotedtext}

  @p{««} See the blog post from last month on the Foundation's "pivot" to
  focus on development and infrastructure: @p{»»}

    @p{(li}@s{(link)} @p{li)}

  @p{««}RE: "The Board appears to have not settled on an exact date": @p{»»}

  @p{««}Settled 11 days ago; see @s{(link)} for the exact dates for the two
  individual seats. @p{»»}

  @p{««}The election dates for the 'affiliate member seat' isn't yet set,
  the process for affiliate organizations to nominate and then cast their
  votes is still being worked out (and you don't need to care, unless you
  are part of the leadership of one of the Foundation's affiliate
  organizations and need to figure out how you and your members will come
  to consensus on how to vote).@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2239}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-07 14:54:43
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=915828.msg10070284@s{hash}msg10070284
@section 3 {tx}

  @s{quotedtext}

  @p{««} "Three sir!" @p{»»}

  @p{««}Actually, 1 and 2 aren't correct: the one-output and only-40-bytes
  checks are "what is a standard transaction" policy rules. If you can get
  a miner to include it in a block, a transaction with 11 100-byte
  OP_RETURN outputs is valid. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2240}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-12 16:55:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=921669.msg10126689@s{hash}msg10126689
@section 3 {tx}

  @s{quotedtext}

  @p{(li} 1  @p{li)}

  @p{««}I don't get to write the headlines, though...@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2241}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-14 17:37:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=921669.msg10153834@s{hash}msg10153834
@section 3 {tx}

  @s{quotedtext}

  @p{««} Really? @p{»»}

  @p{««}If your luddite parents' computer might already be compromised,
  they cannot securely connect to coinbase (or circle or any other
  easy-enough-for-a-luddite-to-use service) to set up an account. The
  might THINK they're connecting to coinbase/circle/whoever, but malware
  could be man-in-the-middle attacking the website they're looking at.
  @p{»»}

  @p{««}They think they're opening an account at
  coinbase/circle/whatever... but they're just giving the attacker all
  their bank account information, getting bitcoin 'deposit' addresses from
  the attacker, etc. Your parents will have no clue until their bank tells
  them about odd wire transfers or they try to send bitcoin somewhere, it
  fails, and coinbase customer support tells them "Sorry, can't help you,
  you don't have an account with us." @p{»»}

  @p{««}I would say the same about traditional online banking, except your
  luddite parents almost certainly already have a relationship with their
  bank, and the bank already knows their name and how to contact them. And
  it is harder for an attacker to man-in-the-middle the fiat banking
  system and get away with it, since identities are tied to bank accounts,
  wire transfers, etc. @p{»»}

  @p{««}I don't know how the "Bitcoin for Luddites" problem will be solved.
  Maybe hardware wallets, maybe hardware authentication tokens, maybe
  Apple or Google will get iPhone or Android security tight enough to
  trust, maybe it will take "come to our branch to set up an account" to
  get good-enough security and usability. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2242}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-14 19:22:53
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=924869.msg10155210@s{hash}msg10155210
@section 3 {tx}

  @p{««}If your system is compromised, and you are using a single-signature
  wallet, then the first time you unlock your wallet ALL your coins are
  gone. @p{»»}

  @p{««}root certificates are not the weak link in that case; the keys
  being on one device is the weak link.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2243}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-14 20:27:40
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=924973.msg10155935@s{hash}msg10155935
@section 3 {tx}

  @p{««}@s{(link)} @p{»»}

  @p{««}There are other threads going back a long way, but I'm too lazy
  right now to dig them up. A search for "maximum block size" or "1MB
  blocks" in the Dev&amp;Tech forum should find them. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2244}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-16 15:42:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=924869.msg10176516@s{hash}msg10176516
@section 3 {tx}

  @s{quotedtext}

  @p{««} Even in that case, the certificate is "@p{(bf}a@p{bf)}" weak link,
  not "@p{(bf}the@p{bf)}" weak link. Think through what would have to fail
  to pull off a steal-bitcoins attack in the multisig-wallet case: @p{»»}

    @p{(li} 1) User has to be directed to an attacker-controlled payment
    website. That means either DNS lookup is compromised or the user's
    connection to the Internet is compromised (weak link number 1).
    @p{li)}


    @p{(li} 2) Attacker serves up a signed PaymentRequest with a valid
    certificate signed by a compromised root certificate authority (weak
    link number 2). @p{li)}

  @p{««} If the attacker can accomplish (1), it is likely they would just
  serve up unsigned payment requests from a non-secure website and bet
  that the user doesn't notice the lack of a padlock in the web browser UI
  and agrees to pay to an unauthenticated bitcoin address. @p{»»}

    @p{(li} @p{(so}(1) is mitigated if the payment website uses HSTS
    headers so any repeat visitors get a HTTPS connection@p{--} that
    pushes the attack to "must compromise both the connection and be able
    to spoof the web server certificate".@p{so)} Strike that, if their
    computer is compromised HSTS headers won't help. @p{»»}

  @p{««}In any case, I wouldn't say the root certificates are a single
  point of failure. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2245}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-17 21:59:06
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=927919.msg10189979@s{hash}msg10189979
@section 3 {tx}

  @p{««}Why would a miner want only half the network to build on their
  block? @p{»»}

  @p{««}That makes no sense... what is the +2hr timestamp miner trying to
  accomplish? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2246}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-17 22:04:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=927196.msg10190019@s{hash}msg10190019
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, please report security-critical issues (including consensus
  bugs) to the bitcoin-security mailing list:
  @p{(link}bitcoin-security@s{at}lists.sourceforge.net@p{link)} @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2247}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-19 23:12:00
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=927919.msg10210818@s{hash}msg10210818
@section 3 {tx}

  @s{quotedtext}

  @p{««} No, it really wouldn't, any more than a business-as-usual
  temporary blockchain race/fork creates confusion or breaks applications.
  Like the one-block fork we had @p{(link}today@p{link)}.@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2248}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-01-31 03:12:28
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10315826@s{hash}msg10315826
@section 3 {tx}

  @s{quotedtext}

  @p{««} I think we should target somebody with a "pretty good" computer
  and a "pretty good" home internet connection. @p{»»}

  @p{««}And assume that network bandwidth, CPU and storage will continue to
  grow at about the rates they've been growing for the last 30 or more
  years (see the wikipedia pages on Moore's Law and Nielson's Law for
  pointers to discussions on those). @p{»»}

  @p{««}250gb per month is plenty for a 20MB block size @p{brk} (20MB every
  ten minutes times 6 blocks per hour times 24 hours/day times 31
  days/month == 90GB; we currently transmit all transaction data twice
  (haven't optimized that yet), so double that and you're still well under
  250gb per month). @p{»»}

  @p{««} I believe it is @p{(it}extremely@p{it)} important to maintain the
  fundamental properties that Satoshi laid out @p{--} because the system
  he described is the system that all of us who own bitcoin bought in to.
  @p{»»}

  @p{««}If the collective decision is to change some of those fundamental
  properties, then there must be @p{(it}extremely@p{it)} good reasons to
  do so. @p{»»}

  @p{««}On the block size issue, Satoshi said on Sun, 02 Nov 2008
  @p{(link}on the metz-dowd cryptography mailing list@p{link)} (in reply
  to a question about scalability): @p{»»}

  @s{quotedtext}

  @p{««} When I first heard about Bitcoin, it was small enough I could read
  everything, and I did, including all of those mailing list posts. The
  promise of a system that could scale up to rival Visa is part of the
  vision that sold me on Bitcoin. @p{»»}

  @p{««}I feel bad suggesting that we limit the block size at all, or that
  the target be home computers and internet connections @p{--} but I think
  there are plausible concerns about centralization risk, and I think
  starting small and scaling up as technology advances is a reasonable
  compromise. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2249}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-01 23:35:10
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10330613@s{hash}msg10330613
@section 3 {tx}

  @s{quotedtext}

  @p{««} What's wrong? @p{»»}

  @p{««}Lets say those million dollar transactions are 250 bytes. That is
  4,000 of them in a 1MB block. @p{»»}

  @p{««}So $40,000 total reward to the miner @p{--} about eight times
  current block reward. @p{»»}

  @p{««}BUT YOU ARE SECURING TRANSACTIONS WORTH SOMETHING LIKE 2,000 TIMES
  MORE VALUABLE THAN TODAY'S TRANSACTIONS (estimated average transaction
  USD value for today's average transaction is about $380). And I
  GUARANTEE that attackers would have a much easier time pulling off a
  double-spend of one million-dollar transaction than 1,000 $1,000
  transactions. @p{»»}

  @p{««}The math for "large value transactions will generate enough fees to
  secure the chain" just doesn't work. @p{brk} The math for "lots of small
  transactions will generate enough fees to secure the chain" might. @p{»»}

  @p{««}Also: @p{»»}

  @p{««}I still haven't heard a coherent argument on why large value
  transactions are necessarily also high-fee transactions. @p{»»}

  @p{««}I'd suggest you go research existing high-value-payment networks
  and see what typical fees are for multi-million dollar transactions.
  FEDWIRE is running at 6 transactions per second, average transaction
  value over $6million, with fees per transaction @p{(bf}UNDER ONE
  DOLLAR.@p{bf)} @p{»»}

  @p{««}Why? Because if you are giving somebody one million dollars for
  something, you almost certainly have built up real-world trust, and
  probably have a longstanding relationship, signed contracts, etc etc.
  @p{»»}

  @p{««}If you think Bitcoin is different, please explain the scenario
  where I send a stranger who I don't trust (so have to rely completely on
  the blockchain) $1million for something. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2250}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-06 01:34:07
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10371991@s{hash}msg10371991
@section 3 {tx}

  @p{««}If I ever go insane and suggest increasing the 21 million coin
  limit, please put me on your ignore list. @p{»»}

  @p{««}I will remind everybody again of Satoshi's second public post where
  he talked about scalability: @p{»»}

  @s{quotedtext}

  @p{««} If you didn't do your homework and thought that Bitcoin == 1MB
  blocks forever, well, that's your fault. @p{»»}

  @p{««}I signed up for a Bitcoin that would scale. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2251}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-17 18:50:50
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10492729@s{hash}msg10492729
@section 3 {tx}

  @s{quotedtext}

  @p{««} Huh what? @p{»»}

  @p{««}I am not proposing infinitely sized blocks, so I obviously
  acknowledge the concept of a too-high limit as being plausible. @p{»»}

  @p{««}If you want to continue the conversation, please be very explicit
  about what problem you think needs solving, and how whatever solution
  you're proposing solves that problem. @p{»»}

  @p{««}We might agree or disagree on both of those points, but we won't
  have a productive conversation if you can't say what problem you are
  trying to solve. @p{»»}

  @p{««}To summarize my position: I see one big problem that need solving:
  @p{»»}

  @p{««}Supporting lots (millions, eventually billions) of people
  transacting in Bitcoin. @p{»»}

    @p{(li}Ideally at as low a cost as possible, as secure as possible,
    and in the most decentralized and censorship-resistant way possible.
    @p{li)}

  @p{««}It is hard to get consensus on HOW to solve that problem, because
  no solution is obviously lowest cost, most secure, and most
  decentralized all at the same time, and different people assign
  different weights to the importance of those three things. @p{»»}

  @p{««}My bias is to "get big fast" @p{--} I think the only way Bitcoin
  thrives is for lots of people to use it and to be happy using it. If it
  is a tiny little niche thing then it is much easier for politicians or
  banks to smother it, paint it as "criminal money", etc. They probably
  can't kill it, but they sure could make life miserable enough to slow
  down adoption by a decade or three. @p{»»}

  @p{««}"Get big fast" has been the strategy for a few years now, ever
  since the project became too famous to fly under the radar of regulators
  or the mainstream press. @p{»»}

  @p{««}The simplest path to "get big fast" is allowing the chain to grow.
  All the other solutions take longer or compromise decentralization (e.g.
  off-chain transactions require one or more semi-trusted entities to
  validate those off-chain transactions). I'm listening very carefully to
  anybody who argues that a bigger chain will compromise security, and
  those concerns are why I am NOT proposing an infinite maximum block
  size. @p{»»}

  @p{««}There @p{(bf}is@p{bf)} rough consensus that the max block size must
  increase. I don't think there is consensus yet on exactly HOW or WHEN.
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2252}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-17 20:19:02
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=956442.msg10493565@s{hash}msg10493565
@section 3 {tx}

  @p{««}Interesting idea, but I'm afraid I disagree with your premise.
  @p{»»}

  @p{««}There is no tragedy-of-the-commons race to zero transaction fees,
  because miners do not have infinite bandwidth, memory or CPU to accept
  and validate transactions. @p{»»}

  @p{««}We used to have a tragedy-of-the-commons situation with zero-fee
  transactions, but we solved that by rate-limiting them based on
  priority. And we have a working market for zero-fee transactions (see
  the graph @p{(link}here@p{link)}). @p{»»}

  @p{««}Assuming network bandwidth is the eventual bottleneck, and assuming
  there is demand for transactions to fill the available network-wide
  bandwidth (even if that demand is transaction spammers), nodes will
  start dropping transactions before they relay them. Prioritizing them
  based on fee paid and dropping the lowest fee/kb transactions will
  result naturally in a working market for fee-paying transactions. @p{»»}

  @p{««}As justusranvier points out, off-the-blockchain deals between
  transaction creators and miners doesn't change that logic, because
  low-fee transactions that are not broadcast break the O(1) block
  propagation assumption and have a direct cost to the miner. @p{»»}

  @p{««} I think you are trying to solve a different problem: I think you
  are trying to ensure that "enough" fees are paid to secure the network
  as the block subsidy goes away. Yes? @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2253}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-19 17:06:47
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=956442.msg10513441@s{hash}msg10513441
@section 3 {tx}

  @s{quotedtext}

  @p{««} I agree. @p{»»}

  @p{««}My guess is that we will end up with a very secure system with a
  modest amount of hashing in the future, because PoW hashing does three
  things: @p{»»}

  @p{««}1) Gives a steady 10-minute 'heartbeat' that limits how quickly new
  coins are produced @p{brk} 2) Makes it expensive to successfully
  double-spend confirmed transactions @p{brk} 3) Makes it expensive to
  censor transactions @p{»»}

  @p{««}The first becomes less important over time as the block subsidy
  halves. @p{»»}

  @p{««}I think we could do a lot to mitigate the second (see @s{(link)}
  for a partly-baked idea). @p{»»}

  @p{««}And I think the third might be mitigated naturally as we scale up
  and optimize the information sent across the network (there will be
  strong incentives to create "boring" blocks that don't include or
  exclude transactions everybody else is excluding or including). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2254}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-19 19:05:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=961335.msg10514902@s{hash}msg10514902
@section 3 {tx}

  @p{««}I think it will depend on the release. @p{»»}

  @p{««}Adoption of 0.10.0 is looking really good:
  @p{(link}@s{(link)}@s{hash}user-agents@p{link)} @p{brk} ... going from about 3%
  of nodes to 12% in just the last three days. @p{»»}

  @p{««}Different versions existing on the network isn't a problem until
  there is some incompatible change in either the consensus code (a hard
  fork) or the p2p networking protocol (and even that doesn't have to be a
  problem if there are "bridge" nodes that speak both versions of the
  protocol and relay blocks/transactions across the incompatible
  networks). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2255}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-25 17:20:15
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=585639.msg10579643@s{hash}msg10579643
@section 3 {tx}

  @p{««}Very nice work, DeathAndTaxes. @p{»»}

  @p{««}The 0.10 release makes almost all P2SH Script forms standard,
  opening up possibilities for working around the 520-byte-push limit.
  @p{»»}

  @p{««}Warning: half baked thoughts off the top of my head here, check my
  work and TEST TEST TEST: @p{»»}

  @p{««}There isn't room in 520-bytes for all the compressed public keys
  needed for m of 16-20. Can we safely move the public keys out of the
  serialized P2SH onto the scriptSig stack? @p{»»}

  @p{««}e.g. go from a scriptSig that looks like: @p{»»}

   @s{code}

  @p{««} to: @p{»»}

   @s{code}

  @p{««} That's easy to do unsafely; ... something ... is just: @p{»»}

   @s{code}

  @p{««} That's unsafe because anybody can redeem it with any 20 keys.
  @p{»»}

  @p{««}To be safe, you need a secure digest of the 20 public keys inside
  the serialized P2SH stuff. We've got HASH160 to create 20-byte digests,
  so we can get 26-bytes-per-pubkey with: @p{»»}

   @s{code}

  @p{««} Using PICK instead of ROLL you can probably save a byte per
  pubkey; if it can be done in 25 bytes then that gets under the
  520-byte-push limit. @p{»»}

  @p{««}Aside: It would've been lovely if Script had a "hash the top N
  items on the stack, and push the result onto the top of the stack"
  operator. Ah well. @p{»»}

  @p{««}BUT you're now putting 33+26 = 59 bytes per key into the scriptSig,
  so the 1650-byte-for-scriptSig-IsStandard limit will bite. If I counted
  everything correctly (and I almost certainly didn't), you could get 1
  through 6 -of-20 as standard (20-of-20 as non-standard but valid). @p{»»}

  @p{««}EDIT: I already see a mistake: pushing 21 onto the stack requires
  two bytes, not one.....@p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2256}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-02-26 21:53:11
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=585639.msg10593597@s{hash}msg10593597
@section 3 {tx}

  @p{««}... I managed to be wrong twice: I forgot about the
  AreInputsStandard check for P2SH transactions that makes any transaction
  with more than 15 signature operations non-standard. @p{»»}

  @p{««}So if you REALLY need a m-of-16-to-20 transaction, use a
  non-standard raw CHECKMULTISIG, don't bother with Script gymnastics to
  try to workaround the 520-byte push limit. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2257}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-05 21:18:27
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=975447.msg10673166@s{hash}msg10673166
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why do you want miners to have an incentive to make smaller
  blocks? @p{»»}

  @p{««}Smaller blocks means fewer transactions, so fewer opportunities to
  collect fees, so less profit. @p{»»}

  @p{««}Miner profit in fiat currency = number of transactions * average
  transaction fee * btc-to-fiat exchange rate @p{»»}

  @p{««}Experience (and common sense) says that more usage of Bitcoin means
  a higher btc-to-fiat exchange rate, so if you want to maximize miner's
  fee revenue then increasing the number of transactions is the obvious
  way to do it. @p{»»}

  @p{««}If you think that putting an artificial cap on the number of
  transactions will increase overall miner profit, then I urge you to find
  a Real Economist and talk to them about the wisdom of trying to use
  production quotas to keep prices artificially high. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2258}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-07 14:12:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=975447.msg10690892@s{hash}msg10690892
@section 3 {tx}

  @s{quotedtext}

  @p{««} Why do we need transaction relayers? What vital function do they
  provide? @p{»»}

  @p{««}Miners need to be connected to each other, and to transaction
  creators (individual users, exchanges, merchants, online wallets, etc).
  @p{»»}

  @p{««}And transaction creators need to be able to connect to miners, but
  it seems to me transaction fees should certainly be enough incentive for
  miners to arrange for there to be plenty of opportunity for transaction
  creators to send them fee-paying transactions (it's cheap to run nodes
  that have tens of thousands of incoming connection slots). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2259}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-07 18:15:01
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=975447.msg10693151@s{hash}msg10693151
@section 3 {tx}

  @s{quotedtext}

  @p{««} Yes, I meant revenue, not profit. @p{»»}

  @p{««}I need to stop saying "profit" entirely, even when I mean
  "profit"@p{--} it has different meanings for economists and ordinary
  people. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2260}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-11 17:50:44
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10739973@s{hash}msg10739973
@section 3 {tx}

  @s{quotedtext}

  @p{««} With economic reasoning like that, I see why Paymium has such low
  transaction volume (if you're making massive profits because your costs
  are so much lower processing so many fewer transactions than the bigger
  exchanges, then I'll adjust my priors). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2261}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-17 14:12:59
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10801226@s{hash}msg10801226
@section 3 {tx}

  @s{quotedtext}

  @p{««}Are you this annoying in person, or just online? @p{»»}

  @p{««}I spent last week talking to some of the largest Bitcoin businesses
  (much bigger than Paymium/Bitcoin-Central or anything anybody in
  @s{hash}bitcoin-assets is involved with), and they all want the maximum block
  size to increase. @p{»»}

  @p{««}The poll in this thread says people support it by a three-to-one
  margin. @p{»»}

  @p{««}It is going to happen sooner or later. I want it to happen sooner
  because Very Bad Things will happen if we get to 100% full 1MB blocks:
  @p{»»}

  @s{quotedtext}

  @p{««} @s{(link)} @p{»»}

  @p{««}I'm busy writing benchmarks, finding bugs in current code, and
  generally making sure nothing will break when we increase the maximum
  block size. If you want to be helpful instead of being an annoying
  troll, I have a TODO list you could help out with. Although the last
  time you agreed to help out, Dave, you didn't follow through on your
  promises (do you remember when you agreed to help with the testnet?).
  @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2262}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-03-17 17:49:42
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=941331.msg10803460@s{hash}msg10803460
@section 3 {tx}

  @p{««}Finally a reasonable question: @p{»»}

  @s{quotedtext}

  @p{««} The problem people are worried about if the maximum block size is
  too high: That big miners with high-bandwidth, high-CPU machines will
  drive out either small miners or I-want-to-run-a-full-node-at-home
  people by producing blocks too large for them to download or verify
  quickly. @p{»»}

  @p{««}An adaptive limit could be set so that some minority of miners can
  'veto' block size increases; that'd be fine with me. @p{»»}

  @p{««}But it wouldn't help with "I want to be able to run a full node
  from my home computer / network connection." Does anybody actually care
  about that? Satoshi didn't, his vision was home users running SPV nodes
  and full nodes being hosted in datacenters. @p{»»}

  @p{««}I haven't looked at the numbers, but I'd bet the number of personal
  computers in homes is declining or will soon be declining@p{--} being
  replaced by smartphones and tablets. So I'd be happy to drop the "must
  be able to run at home" requirement and just go with an adaptive
  algorithm. Doing both is also possible, of course, but I don't like
  extra complexity if it can be helped. @p{»»}

  @p{««}It is hard to tease out which problem people care about, because
  most people haven't thought much about the block size and confuse the
  current pain of downloading the chain initially (pretty easily fixed by
  getting the current UTXO set from somebody), the current pain of
  dedicating tens of gigabytes of disk space to the chain (fixed by
  pruning old, spent blocks and transactions), and slow block propagation
  times (fixed by improving the code and p2p protocol). @p{»»}

  @p{««} PS: my apologies to davout for misremembering his testnet work.
  @p{»»}

  @p{««}PPS: I am always open to well-thought-out alternative ideas. If
  there is a simple, well-thought-out proposal for an adaptive blocksize
  increase, please point me to it. @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2263}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-04-03 20:52:54
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1006929.msg10974409@s{hash}msg10974409
@section 3 {tx}

  @s{quotedtext}

  @p{««} You can't, the reference implementation wallet always pays
  some-amount-per-1000-bytes-of-the-transaction. @p{»»}

  @p{««}The rules for the 0.10 release are: @p{»»}

    @p{(li}  By default, you always pay a fee (this is different from previous
    releases that would send transactions without a fee if they had high
    enough priority) (run with -sendfreetransactions=1 to get the old
    behavior of sending high-priority transactions without a fee)  @p{li)}

    @p{(li} By default, the fee-per-kilobyte is estimated based on
    recent transaction confirmation history. @p{li)}

  @p{««}To get close to what you want (pay a fixed fee per transaction),
  run with -paytxfee=0.whatever : that tells the wallet code to pay
  0.whatever BTC per 1000 bytes. Most transactions are about 500 bytes
  big. @p{»»}

  @p{««}See here: @s{(link)} ... for how high to make -paytxfee=0.whatever
  based on how long you're willing to wait for the first confirmation
  (that page graphs estimates from the latest&amp;greatest fee estimation
  code from Alex Morcos that will hopefully be in the 0.11 Bitcoin Core
  release). @p{»»}

# ----------------------------------------------------------------------
@section 2 {ms2264}
@section 3 {au}
  Gavin Andresen
@section 3 {dt}
  2015-04-06 22:30:39
@section 3 {ht}
  https://bitcointalk.org/index.php?topic=1013053.msg11003988@s{hash}msg11003988
@section 3 {tx}

  @p{««}Secretary work? @p{»»}

  @p{««}Lindsay WAS the Foundation at the beginning, and did EVERYTHING
  (including single-handedly organizing the San Jose conference). @p{»»}

  @p{««}She, like me, got a huge salary boost because the Foundation's
  original policy was to set the exchange rate for paying salaries once
  per quarter. That policy changed pretty quickly (neither Lindsay or I
  had any influence on our own salaries or the policies for how they were
  paid) to "use the CoinDesk price index on payday." @p{»»}

  @p{««}You have to remember that even simple things like "which exchange
  rate should be used to pay employees" didn't have simple answers back
  then (nobody had created a cross-exchange, volume-weighted price index).
  @p{»»}

  @p{««}I believe she left the Foundation partly because of annoying
  misogynistic Internet trolls like the ones found in this very thread....
