Kicking the Hornet's Nest - part 15
# Kicking the Hornet's Nest - third edition - part 15
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by [crrdlx](@crrdlx), npub:
```
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
```
### Kicking the Hornet's Nest pages 325 - 350
##### BitcoinTalk
#### Re: Bitcoin snack machine (fast transaction problem)
##### 2010-07-18 01:59:15 UTC - [-](https://bitcointalk.org/index.php?topic=423.msg3867#msg3867)
[Quote from: llama on July 18, 2010, 12:03:29 AM](https://bitcointalk.org/index.php?topic=423.msg3836#msg3836)
This is a good start, but still not impermeable.
I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.
Quote
(for example, by refusing to propogate word of the transaction at the vending machine)
No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes.
##### BitcoinTalk
#### Re: Source code documentation
##### 2010-07-18 15:12:54 UTC - [-](https://bitcointalk.org/index.php?topic=393.msg3999#msg3999)
They're only intended for intrepid programmers who read the sourcecode.
##### BitcoinTalk
#### Re: URI-scheme for bitcoin
##### 2010-07-18 16:06:16 UTC - [-](https://bitcointalk.org/index.php?topic=55.msg4008#msg4008)
[Quote from: lachesis on June 16, 2010, 06:14:05 AM](https://bitcointalk.org/index.php?topic=55.msg1597#msg1597)
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
That's what I thought too.
[Quote from: sirius-m on June 16, 2010, 08:26:14 AM](https://bitcointalk.org/index.php?topic=55.msg1598#msg1598)
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...
If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.
I'll get started on adding the password field.
Martii Malmi (AKA Sirius) “COPA trial” email #209
Date: Sun, 18 Jul 2010 16:23:21 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: wiki
To: Martti Malmi <mmalmi@cc.hut.fi>
http://www.bitcoin.org/smf/index.php?topic=393.msg3785#msg3785
AndrewBuck:
EDIT: The wiki doesn't seem to be sending the registration e-mail so I
can log in to edit, is there some problem with the server or something?
-Buck
Martii Malmi (AKA Sirius) “COPA trial” email #210
Date: Sun, 18 Jul 2010 16:23:10 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Fwd: bitcoin hosting
To: mmalmi@cc.hut.fi
Please promise me you won't make a switch now. The last thing we need
is switchover hassle on top of the slashdot flood of work we've got now.
I'm losing my mind there are so many things that need to be done.
Also, it would suck to be on a smaller, less reliable host just to save
a measly $20.
I will try to think of a polite way to ask the donor if he sent it, but
right now there are other higher priority things that are going to bump
even that for a few days.
Would a donation of bitcoins help in the short term?
mmalmi@cc.hut.fi wrote:
> Rackspace has very good support, good backend, good connections and
> nicely scaling cloud based virtual servers. I got this offer from Thufir:
>
> -----
> Hi Sirius,
>
> Check out www.citrusdesignstudio.com. You will see through the portfolio
> that
> I am a real business with many clients.
>
> That is my business that I provide managed hosting through.
> I also do unmanaged VPSes.
>
> Normally I would charge $15/mo for 512MB.
> I will do it for $10/mo for you.
>
> To see my pricing, go to www.linnode.com. I match everything they have
> except
> their great panel -- you have to email or call my people.
>
> I provide VPS services normally for 3/4ths the posted cost on linnode.com.
> (Rackspace is even more expensive.)
>
> I will do it for 1/2 of linnode's price for you.
>
> It scales linerally just like linnodes, so for 2048 MB of memory, I would
> charge $40, etc.
>
> Later!
> -----
>
> That would be worth considering, if they have good datacenters and
> connections. $10 / month is about $20 less than what Rackspace costs. On
> the other hand, Rackspace prices are no problem if the donation is to
> arrive.
>
##### BitcoinTalk
#### Re: Bitcoin 0.3.2 released
##### 2010-07-18 18:58:21 UTC - [-](https://bitcointalk.org/index.php?topic=437.msg4037#msg4037)
The change list is basically encompassed by what's listed in the first message. Everyone should upgrade to get the important security improvements.
Minimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again. You can still re-enable the option with "-minimizetotray" if you want to use it anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them. Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature.
##### BitcoinTalk
#### JSON-RPC password
##### 2010-07-18 20:49:22 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4059#msg4059)
I uploaded to SVN my changes to add a password to JSON-RPC. If you're set up to build, please test it.
The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password> -- runs with JSON-RPC port open
bitcoind -rpcpw=<password> -- daemon with password
If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too. I'm not sure but I think they may want to use different passwords for the two.
It gives a warning if you don't set a password.
All commands now require the password as the first parameter. It'll tell you that if you run "bitcoind help".
The central code:
// Check password
if (params.size() < 1 || params[0].type() != str_type)
throw runtime_error("First parameter must be the password.");
if (params[0].get_str() != strRPCPassword)
{
if (strRPCPassword.size() < 15)
Sleep(50);
begin = strRequest.end();
printf("ThreadRPCServer incorrect password attempt ");
throw runtime_error("Incorrect password.");
}
Any comments on these decisions?
1) if (strRPCPassword.size() < 15) Sleep(50); -- this means if it's a short password, it'll wait 50ms after each attempt. This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan. This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15. If you want to close the DoS possibility, just use a password 15 characters or longer.
2) begin = strRequest.end(); -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password. This is so you can't stuff it with millions of password attempts in one packet. What do you think, is this the right thing to do? (multiple invocation is probably almost never used anyway)
I also fixed the two duplicated commands listed in the help:
getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>
##### BitcoinTalk
#### Re: MSVC build & SHA-256
##### 2010-07-18 21:24:09 UTC - [-](https://bitcointalk.org/index.php?topic=453.msg4068#msg4068)
OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256. SHA256 begins by wrapping your data in a specially formatted buffer. Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do. It's intended that the time is amortised if you were hashing many KB or MB of data. In BitcoinMiner, we format the buffer once and keep reusing it.
If you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great! (although, keep licensing in mind) The one we have is the only one I tried, so there's significant chance for improvement.
When I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256. That's a lot of time for them to come up with better stuff. SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be. Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.
(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)
##### BitcoinTalk
#### Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.
##### 2010-07-18 21:56:18 UTC - [-](https://bitcointalk.org/index.php?topic=431.msg4073#msg4073)
Typically, over 25,000 BTC.
##### BitcoinTalk
#### Re: Did block generation crawl to a halt?
##### 2010-07-18 23:35:27 UTC - [-](https://bitcointalk.org/index.php?topic=441.msg4095#msg4095)
Nice graph! A moving average to smooth it out would be nice.
[http://nullvoid.org/bitcoin/statistix.php](http://nullvoid.org/bitcoin/statistix.php) says 212 blocks in the last 24 hours, or 8.8 per hour.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-19 04:43:13 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4169#msg4169)
Right, that is quite a bit better.
Can you give me any examples of other stuff that does it that way? (and what the command line looks like)
The main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right? (any ideas what I should name the switch?)
##### BitcoinTalk
#### Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
##### 2010-07-19 16:01:38 UTC - [-](https://bitcointalk.org/index.php?topic=479.msg4263#msg4263)
Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.
We're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.
Update:
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-19 16:20:50 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4268#msg4268)
So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the "no password is set" warning, it could tell you where the file is and what to do.
What is the most popular and common settings file format?
HTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits? Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.
[Quote from: gavinandresen on July 19, 2010, 12:02:39 PM](https://bitcointalk.org/index.php?topic=461.msg4215#msg4215)
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.
You're also confusing me, what do you mean? Did I do something unintended?
##### BitcoinTalk
#### Re: They want to delete the Wikipedia article
##### 2010-07-20 18:38:28 UTC - [-](https://bitcointalk.org/index.php?topic=342.msg4508#msg4508)
Bitcoin is an implementation of Wei Dai's b-money proposal [http://weidai.com/bmoney.txt) on Cypherpunks ">http://en.wikipedia.org/wiki/Cypherpunks(http://unenumerated.blogspot.com/2005/12/bit-gold.html(http://unenumerated.blogspot.com/2005/12/bit-gold.html)The timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment?
It would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.
If you post in [http://en.wikipedia.org/wiki/Wikipedia:Articlesfordeletion/Bitcoin](http://en.wikipedia.org/wiki/Wikipedia:Articlesfordeletion/Bitcoin)please don't say "yeah, but bitcoin is really important and special so the rules shouldn't apply" or argue that the rule is dumb or unfair. That only makes it worse. Try to address how the rule is satisfied.
Search "bitcoin" on google and see if you can find more big references in addition to the infoworld and slashdot ones. There may be very recent stuff being written by reporters who heard about it from the slashdot article.
I hope it doesn't get deleted. If it does, it'll be hard to overcome the presumption. Institutional momentum is to stick with the last decision. (edit: or at least I assume so, that's how the world usually works, but maybe Wiki is different)
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-21 00:05:20 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4577#msg4577)
Still need to know what's the most typical settings file format on Linux. Is there a standard file extension? I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes. I think what I usually see is like:
# comment
setting=value
Is there a settings file thing in Boost?
When you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?
Gavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters. (JSON-RPC is fine) Still under construction.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-21 05:51:34 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4646#msg4646)
I was researching config file formats, here's a comparison.
YAML is massive. I'm not sure there's a lightweight easy to build library we can integrate into our project. Seems overkill.
JSON is tempting and I'm inclined to like it, but two main sticking points:
1) No comments! How can you have a config file where you can't comment out a line to disable it?
2) Not very user friendly to have to "quote" all the strings, including the keys, and also have to remember the comma at the end of lines.
{
"key" : "value",
}
I suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or "//"?), concatenate them into a string and pass it to JSON, so you could go:
# comment
"key" : "value", # still have to remember the comma
"key2" : "value", // comment like this or both
Boost has boost::program_options.
We could read lines ourselves and feed them into a map<string, string> mapConfig.
while (!eof)
read line
if '#' found, truncate line
split line at first ':' -> key, value
mapConfig.insert(key, value)
If we use the syntax:
# comment
key : value
If we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed. If an option needs a list or more structured data, it could always parse its value as json:
key : ["item1", "item2", "item3"]
Although it has to be all on one line then.
I guess I'm leaning towards self parsed mapConfig:
# comment
key : value
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-21 16:07:57 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4758#msg4758)
[Quote from: gavinandresen on July 21, 2010, 12:11:10 PM](https://bitcointalk.org/index.php?topic=461.msg4709#msg4709)
_I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used "key value"
5 used "key=value"_
Thanks for that survey!
I find "key value" a little unnatural. There ought to be a more definite separator between key and value that suggests assignment. The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it. # seems more clear
key some full sentence with spaces in it. # than this
Allright then, lets go with self-parsed mapConfig, syntax:
# comment
key=value
file extension .conf. What's the filename, is it /.bitcoin/settings.conf or /.bitcoin/bitcoin.conf or what?
I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # "this sentence would be this"
key = value # guess this is ok too
nextkey = value
right = justified
The normal syntax should be "key=value", but you can't blame people for the occasional "key = value".
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-21 17:31:09 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4775#msg4775)
boost::program_options has the same "key=value" format. Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction. We can use more features if we want later.
Lets go ahead with HTTP basic authentication instead of password as a parameter.
Martii Malmi (AKA Sirius) “COPA trial” email #213
Date: Wed, 21 Jul 2010 23:28:33 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Donation
To: mmalmi@cc.hut.fi
mmalmi@cc.hut.fi wrote:
> Good news: I received the donation of $3600. At least the hosting costs
> are no problem anymore.
That's great! I'll let him know it was received and thank him.
It might be a long time before we get another donation like that, we
should save a lot of it.
Spend what you need on hosting. Email me a simple accounting when you
take out money for expenses, like:
-$60 rackspace monthly
$2540 balance
> What do you think of the idea to offer rewards of $100-200 to the first
> 5-10 established companies that start accepting Bitcoin? We'd also
> assign them a dedicated support person to help with integration. I have
> companies like prq.se, ipredator.se, relakks.com or perfect-privacy.com
> in mind. We could also make the offer public.
$100-200 is chump change if they're a serious company, it would only
make us sound small.
What they need most is confidence they can convert it to fiat currency.
That VOIP company essentially said so in a recent post. The best
thing we can do is make sure there's cash available to cash out and
support and steady the conversion rate.
The money is leveraged better that way too. Theoretically, imagine 10
businesses have their eye on a $100 bill being offered for bitcoins, but
don't actually cash out because they know it's there if they need it.
That one $100 bill allowed 10 different people to act like their 5000
bitcoins were equivalent to $100.
I think we should allocate $1000 at this point to your exchange.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-22 02:34:23 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg4928#msg4928)
[Quote from: gavinandresen on July 22, 2010, 01:11:26 AM](https://bitcointalk.org/index.php?topic=461.msg4908#msg4908)
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(WXMSW) && wxUSE_GUI
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password> ", "Bitcoin", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password> ");
#endif
Martii Malmi (AKA Sirius) “COPA trial” email #215
Date: Fri, 23 Jul 2010 16:59:42 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Donation
To: mmalmi@cc.hut.fi
>> I think we should allocate $1000 at this point to your exchange.
>
> Alright, I'll add $1000 dollars to the exchange reserves. That way I can
> offer more stable pricing.
>
> A week ago somebody bought coins with 1000 €. That was probably meant as
> a donation to some extent, since 1000 € would have bought him a lot more
> coins at bitcoinmarket.com than at my service.
Interesting, so how is the balance between purchases of coins and cash
going?
Btw, are you able to use my builds of bitcoind on your host, or do you
have to build it yourself?
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-23 17:07:40 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5337#msg5337)
[Quote from: gavinandresen on July 23, 2010, 03:11:45 PM](https://bitcointalk.org/index.php?topic=461.msg5296#msg5296)
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-- just use the [http://user:pass@host:port/](http://user:pass@host:port/) URL syntax.
Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-23 17:14:31 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5338#msg5338)
Gavin's changes look good. I think everything is complete. Here's a test build, please test it!
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip)
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz)
##### BitcoinTalk
#### Re: bitcoind not responding to RPC
##### 2010-07-23 17:23:47 UTC - [-](https://bitcointalk.org/index.php?topic=548.msg5339#msg5339)
If I recall correctly, 500 is the prescribed status code for JSON-RPC error responses. There is still a JSON response in the body of the reply telling the explanation of the error, which could be something like {"result":"","error":"bitcoin address not found","id":"1"}.
##### BitcoinTalk
#### Faster initial block download (5x faster)
##### 2010-07-23 18:24:56 UTC - [-](https://bitcointalk.org/index.php?topic=550.msg5349#msg5349)
By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes.
The database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.
I only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.
I built a test build if you'd like to start using it:
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip)
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz)
These binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.
I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.
There are no changes to the way it handles wallet.dat. This change is only for blk.dat and the non-critical addr.dat. You can always delete blk.dat if it gets screwed up and let it re-download.
##### BitcoinTalk
#### Re: Faster initial block download
##### 2010-07-23 20:13:27 UTC - [-](https://bitcointalk.org/index.php?topic=550.msg5378#msg5378)
[Quote from: knightmb on July 23, 2010, 07:32:58 PM](https://bitcointalk.org/index.php?topic=550.msg5369#msg5369)
Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?
Not really. I'll change it to 1000 next time.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-23 20:39:03 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5383#msg5383)
I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain "rpcpassword", but what if it contains "rpcpassword="?
I can see both points.
What if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library? Should they be able to explicitly disable the password requirement?
OTOH, what if there's a template conf file, with
rpcpassword= # fill in a password here
There are many systems that don't allow you to log in without a password. This forum, for instance. Gavin's point seems stronger.
BTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?
##### BitcoinTalk
#### Re: JSON-RPC Multiple Invocations
##### 2010-07-24 00:59:08 UTC - [-](https://bitcointalk.org/index.php?topic=528.msg5416#msg5416)
Obviously it's a bug that it repeats the header.
I was trying to follow the 1.0 spec: [http://json-rpc.org/wiki/specification](http://json-rpc.org/wiki/specification) It called for multiple invocation.
I think they mean it's like this, but I'm not sure:
Post:
{"method": "postMessage", "params": ["Hello all!"], "id": 99}
{"method": "postMessage", "params": ["I have a question:"], "id": 101}
Reply:
{"result": 1, "error": null, "id": 99}
{"result": 1, "error": null, "id": 101}
I can't remember where I think I saw that it's supposed to send back HTTP status 500 for an error reply. If it contains multiple responses and one is an error, I wonder if that makes the status 500 for the whole thing, I guess so. Maybe it should always return 200. I think someone sounded like the 500 might be causing a problem.
This probably gets fixed after 0.3.3. Until then, just use single invocation. I wonder if any JSON-RPC package even supports multiple invocation, probably not.
It would be nice if we could pin down better how multiple-invocation is supposed to work, if at all, before trying to fix it, and whether returning HTTP status 500 for error response is right.
Martii Malmi (AKA Sirius) “COPA trial” email #217
Date: Sat, 24 Jul 2010 15:38:53 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Donation
To: mmalmi@cc.hut.fi
> A week ago somebody bought coins with 1000 €. That was probably meant as
> a donation to some extent, since 1000 € would have bought him a lot more
> coins at bitcoinmarket.com than at my service.
They probably couldn't have gotten that large of a trade on
bitcoinmarket.com.
##### BitcoinTalk
#### Re: bitcoind not responding to RPC
##### 2010-07-24 01:15:58 UTC - [-](https://bitcointalk.org/index.php?topic=548.msg5419#msg5419)
Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply? I can't remember where I picked that up, maybe it's wrong. It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself. (and maybe that's what it said and I forgot and spread 500 to all error responses)
##### BitcoinTalk
#### Re: Warning: don't use -server or bitcoind on a machine where you web browse
##### 2010-07-24 02:29:09 UTC - [-](https://bitcointalk.org/index.php?topic=479.msg5432#msg5432)
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
##### BitcoinTalk
#### Version 0.3.2.5 -- please test!
##### 2010-07-24 03:32:52 UTC - [-](https://bitcointalk.org/index.php?topic=556.msg5443#msg5443)
Please test 0.3.2.5 in preparation for the 0.3.3 release! This build is looking good and should be the one that goes into 0.3.3. I encourage you to go ahead and upgrade now if you're on Windows or Linux.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
Download here:
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip)
[http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz)
Thanks!
##### BitcoinTalk
#### Re: Reading/Writing Blocks and FLATDATA
##### 2010-07-24 04:04:20 UTC - [-](https://bitcointalk.org/index.php?topic=555.msg5450#msg5450)
FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
##### BitcoinTalk
#### Re: a simple traffic load test run
##### 2010-07-25 14:46:33 UTC - [-](https://bitcointalk.org/index.php?topic=567.msg5694#msg5694)
Was that on the test network?
[http://BitcoinTalk.org/index.php?topic=363.0](http://bitcointalk.org/index.php?topic=363.0)
##### BitcoinTalk
#### Re: a simple traffic load test run
##### 2010-07-25 15:29:52 UTC - [-](https://bitcointalk.org/index.php?topic=567.msg5698#msg5698)
Please do these tests on the test network. That's what it's for. Thanks.
##### BitcoinTalk
#### Bitcoin 0.3.3 released -- PLEASE UPGRADE
##### 2010-07-25 16:55:09 UTC - [-](https://bitcointalk.org/index.php?topic=570.msg5707#msg5707)
Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and 0.3.3.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
##### BitcoinTalk
#### Re: Stealing Coins
##### 2010-07-25 17:45:22 UTC - [-](https://bitcointalk.org/index.php?topic=571.msg5712#msg5712)
It's best if you tell it to me privately so it can be fixed first.
I just e-mailed you my e-mail address. (or you could PM me here)
##### BitcoinTalk
#### Re: Stealing Coins
##### 2010-07-25 19:06:23 UTC - [-](https://bitcointalk.org/index.php?topic=571.msg5724#msg5724)
Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA.
##### BitcoinTalk
#### Re: Stealing Coins
##### 2010-07-25 20:01:40 UTC - [-](https://bitcointalk.org/index.php?topic=571.msg5740#msg5740)
[Quote from: knightmb on July 25, 2010, 07:44:02 PM](https://bitcointalk.org/index.php?topic=571.msg5736#msg5736)
_If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456._
You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.
When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.
Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.
He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt.
##### BitcoinTalk
#### Re: Stealing Coins
##### 2010-07-25 20:48:01 UTC - [-](https://bitcointalk.org/index.php?topic=571.msg5754#msg5754)
Quote
Here is a paper that claims to find SHA-1 collisions in 252 crypto operations. And optimally secure hash would take 280 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
280 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2160 bits. Although, if you were trying to crack any one of 1 million (220) transactions, you could do a partial birthday attack 2160/220 = 2140.
Bitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as:
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.
For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-25 21:34:29 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5767#msg5767)
[Quote from: lachesis on July 25, 2010, 07:52:35 PM](https://bitcointalk.org/index.php?topic=461.msg5738#msg5738)
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
Code:
_...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk_
_It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients.
This can be solved by removing the newlines (and maybe ' 's) from result at the end of the Base64Encode function:_
Code:
_result.erase(std::remove(result.begin(), result.end(), ' '), result.end());
result.erase(std::remove(result.begin(), result.end(), ' '), result.end());_
+1 to you for having such a long password that you found this bug.
Uploaded to SVN as rev 110.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-25 21:44:16 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5769#msg5769)
[Quote from: BitLex on July 25, 2010, 08:45:38 PM](https://bitcointalk.org/index.php?topic=461.msg5753#msg5753)
_i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen([http://username:password@localhost:8332/](http://username:password@localhost:8332/))), nor my curl-sample (using setopt CURLOPTHTTPAUTH, CURLAUTHBASIC) seem to work._
That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong.
I hope it's not going to put up this much of a fight for all PHP users.
Looks like we've got the Fortran scenario already.
##### BitcoinTalk
#### Re: JSON-RPC password
##### 2010-07-25 21:51:31 UTC - [-](https://bitcointalk.org/index.php?topic=461.msg5771#msg5771)
[Quote from: gavinandresen on July 25, 2010, 09:38:19 PM](https://bitcointalk.org/index.php?topic=461.msg5768#msg5768)
Great catch! Simpler fix is to specify the BIOFLAGSBASE64NONL in the rpc.cpp/EncodeBase64 function
SVN rev 111
##### BitcoinTalk
#### Re: md5?
##### 2010-07-25 22:06:57 UTC - [-](https://bitcointalk.org/index.php?topic=458.msg5772#msg5772)
For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later.
[http://www.bitcoin.org/SatoshiNakamoto.asc](http://www.bitcoin.org/SatoshiNakamoto.asc)
##### BitcoinTalk
#### Re: Stealing Coins
##### 2010-07-25 22:27:36 UTC - [-](https://bitcointalk.org/index.php?topic=571.msg5778#msg5778)
Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said "prime numbers". ECDSA doesn't take much time to generate a keypair.
##### BitcoinTalk
#### bitcoind without wxWidgets
##### 2010-07-26 17:23:33 UTC - [-](https://bitcointalk.org/index.php?topic=576.msg5904#msg5904)
I replaced the last of the few wxBase dependencies in bitcoind.
bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.
main(int argc, char* argv[]) is added to init.cpp. CMyApp and the Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren't linked by bitcoind.
The makefiles have -DGUI to control whether the GUI is used.
I test compiled MinGW, VC and Ubuntu. I don't know if I broke the Mac OSX build, someone will need to check that.
##### BitcoinTalk
#### Re: Bitcoin x64 for Windows
##### 2010-07-26 18:41:31 UTC - [-](https://bitcointalk.org/index.php?topic=501.msg5920#msg5920)
[Quote from: Olipro on July 26, 2010, 06:39:17 AM](https://bitcointalk.org/index.php?topic=501.msg5815#msg5815)
_Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS._
Is that still starting from Crypto++? Lets get this into the main sourcecode.
Martii Malmi (AKA Sirius) “COPA trial” email #218
Date: Mon, 26 Jul 2010 19:22:08 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11'
To: mmalmi@cc.hut.fi
>> Btw, are you able to use my builds of bitcoind on your host, or do you
>> have to build it yourself?
>
> I had to build it myself. It had the same problem that has been reported
> on the forums: /usr/lib/libstdc++.so.6: version `GLIBCXX3.4.11' not found._
Wish I could figure out how to fix that. What version of GLIBCXX does
your system have?
Make sure you upgrade to Bitcoin 0.3.3 as soon as possible.