While we ponder this, if you are worried about this, there is a fairly straightforward workaround that will make you immune from this.

Run two bitcoin daemons.  One that is a full peer in the network, but has an empty, never-used wallet.

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

RE: "I better alert people before they can be tracked" :

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.

correction: bitcoin-qt/bitcoind command-line arguments have a single-dash, so it would be
  bitcoin-qt -server

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

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

Thanks for helping test!  Latest version fixes the p2sh issue.

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


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.

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.

There are three 0.5 BTC bounties available for people who will help us test the upgrade-to-release-0.8 code.

I'm looking for:

CLAIMED: Somebody running (or willing to install and sync-up) bitcoind/bitcoin-qt version 0.3.24
(need to test upgrading from a very old version of Bitcoin)

CLAIMED: Somebody running a version of Windows with their bitcoin data directory on a FAT32 filesystem
(need to test upgrading on a very old filesystem)

CLAIMED: Somebody running Windows XP with an NTFS filesystem
(need to test upgrading on a very old operating system)


Detailed instructions on how to test and then claim a bounty are here:
  https://github.com/gavinandresen/QA/blob/master/HardLinksUpgrade.md

Yes, please do a proof-of-concept on testnet.

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:


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.

If you've got easy_install (does OSX 10.6 comes with easy_install ?), then try:

    easy_install jsonrpc

Or grab jgarzik's version from github:
   https://github.com/jgarzik/python-bitcoinrpc

If you're interested in coin control, and you're comfortable with python and the command-line, then I could use your help.

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.

But since it touches the wallet it needs thorough testing.

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?

Test plan:
  https://github.com/gavinandresen/QA/blob/master/SpendFrom.md

Code:
  https://github.com/gavinandresen/bitcoin-git/tree/spendfrom/contrib/spendfrom

As was pointed out, getrawtransaction <txid> 1    will do the decode for you.

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 http://www.jsonrpc.org/specification#batch

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

If you want to do a really good job, though, you'll need:
  + Lots of people participating and/or
  + Lots of time so your mixes are spread out over time

The 'lots of people' will take time, because the mixing code needs very high trust since it'll be spending your coins.

The 'lots of time' might be a practical problem, because the mixer needs your wallet to be unlocked so it can sign mixing transactions.

Somebody should create a working prototype and then for a Bitcoin Foundation grant to fund the web service for a year...

So is there a banking term for an account that requires multiple authorizations for spending?

I ain't never been a CFO or an accountant, so I don't know nuthin about that stuff...

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

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.

Because people like you noticed that it isn't quite right, but didn't bother to change it?

RE: "multisig transactions" :

I did some high-level multisig design work a couple of months ago:
  https://gist.github.com/4039433
and
  https://moqups.com/gavinandresen/no8mzUDB/

... and had these thoughts about terminology:

Yes, those instructions should work, but build-osx.txt tells you how to build bitcoind.  See
  https://github.com/bitcoin/bitcoin/blob/master/doc/readme-qt.rst
... for very similar instructions on building Bitcoin-Qt

readme-qt.rst suggests downloading and installing the `Qt Mac OS X SDK` from the QT website, but you can also:
  port install qt4-mac

If something doesn't work, post here, or, even better, submit a patch for the documentation.

theymos is correct; if all the inputs have a UINT_MAX sequence number then lockTime is ignored.


Yes, they're supported by the network.


No, there is no easy way to create such a transaction using the reference code.

_{* Super-duper-bitcoin-ninjas like gmaxwell who edit raw transaction hex to set lock times / sequence numbers don't count.}

In my experience, developers are really good at either ignoring documentation or interpreting it in a way different than the way the author intended.

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.

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.

I may just be cynical because I spent so much time in 1997 working on the ISO/IEC-14772-1 Official, Formal Standard.

That is ascii for 'script' -- and was an unfortunate bug in somebody's software, if I recall correctly.


Excellent! The first step to bitcoin development enlightenment is realizing that you are a part of the process...

So... maybe https://en.bitcoin.it/wiki/Tonal_Bitcoin  needs some editing in the same spirit that he's editing other pages...
 

(darn, nanotube protected it...)
(ps to nanotube: that page should be deleted, in my humble opinion)