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.

I'd suggest using a standard, existing format instead of inventing a new one.

Either get rid of the version number and do standard CSV:

Or maybe .ini-format, with each private key a different section:
(bitcoin already contains .ini-file-parsing code, from boost)


I think there are lots of advantages to using an already-standard file format.

PHP 5.3.3. on my mac gives:

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.

I tried it... got -999.04 on my Mac and Linux machines.  What platform gives the wrong answer?

Sticky for creating a pull request:  good idea.

JollyGreen: if you know, or are willing to learn, git then working from the git repo ( https://github.com/bitcoin/bitcoin )is smoother.  github has built-in support for turning a development branch into a pull request.

Who's that woman:
  Anna Lee

I don't know nuthin 'bout changing video default images.

If anybody does, I'd be happy to replace or tweak the link to the video at bitcoin.org.

Something like this is possible (I've been thinking about doing it, although I have higher priority things on my TODO list):

• 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.
• Sophisticated user uploads that file to a "Prove I Paid" website, which checks the signatures and adds info to the database.
• 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.

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.

You know, I was looking at the PayPal payment API yesterday, and $1.01 is sent as... 1.01

"transmitting" != "calculations"

That's just dumb.

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-- you'll just either lose precision as it gets squeezed into a 32-bit float or get a 32-bit-integer-overflow error.

Is there a PHP implementation that does not use double-precision floating point?
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.

And mizerydearia:  re: the witcoin issue:  You say:
"I see the transaction as 0.94 However, http://json-rpc.org/ retrieves the data as 0.93999999999999994671"

So why when you display that value are you truncating it instead of rounding it to 8 decimal places?
For example:

... or to convert to an integer-number-of-base-unit:

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?

Who knows enough about wxWidgets to add a checkbox to the Settings UI for "Enable UpNP" (grayed out #ifndef UPNP...)?  Wanna coordinate with BlueMatt to get that done?

Seems like this feature doesn't need to be part of the RPC interface-- why not just (ignoring error handling/etc) do the equivalent of:


... from whatever code is calling the RPC?

In my head I was imagining a way of telling bitcoin to subscribe to some service(s) that did the mapping-- 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.

I haven't looked at genjix' patch, and haven't thought deeply about security issues-- but I bet there are lots...

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

According to the PHP manual:

I added a Python JSON-RPC library example on the Proper Money Handling wiki page.

The Donate: address is hiding down at the bottom of the page:  15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC
... and I just updated my forum signature, too.

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?

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.

Well, imagine an attacker did manage to surround your node.
What can they do?

a) Dropping outgoing transactions-- a send-coins denial-of-service.
b) Dropping incoming transactions-- a 0-confirmation-receive-coins denial-of-service

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.

c) Dropping new block announcements (that would be a 1+-confirmation-receive-coins DoS)
d) ... and maybe feeding the attacked node attacker-generated blocks

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

RE: 25 outbound connections instead of 8:

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.

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

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.

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.

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.

Making the fee transaction depend on the block's coinbase would run afoul of this code in CTransaction::ConnectInputs:

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

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

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.