Bitcoin Forum
May 25, 2019, 04:27:36 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 »
281  Bitcoin / Bitcoin Discussion / Re: Warning: don't use -server or bitcoind on a machine where you web browse on: July 24, 2010, 02:29:09 AM
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
282  Bitcoin / Bitcoin Technical Support / Re: bitcoind not responding to RPC on: July 24, 2010, 01:15:58 AM
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)
283  Bitcoin / Bitcoin Technical Support / Re: JSON-RPC Multiple Invocations on: July 24, 2010, 12:59:08 AM
Obviously it's a bug that it repeats the header.

I was trying to follow the 1.0 spec:   It called for multiple invocation.

I think they mean it's like this, but I'm not sure:

{"method": "postMessage", "params": ["Hello all!"], "id": 99}
{"method": "postMessage", "params": ["I have a question:"], "id": 101}

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

284  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 23, 2010, 08:39:03 PM
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?
285  Bitcoin / Development & Technical Discussion / Re: Faster initial block download on: July 23, 2010, 08:13:27 PM
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.
286  Bitcoin / Development & Technical Discussion / Faster initial block download (5x faster) on: July 23, 2010, 06:24:56 PM
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:

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.
287  Bitcoin / Bitcoin Technical Support / Re: bitcoind not responding to RPC on: July 23, 2010, 05:23:47 PM
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"}.
288  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 23, 2010, 05:14:31 PM
Gavin's changes look good.  I think everything is complete.  Here's a test build, please test it!
289  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 23, 2010, 05:07:40 PM
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/ 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.
290  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 22, 2010, 02:34:23 AM
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>\n", "Bitcoin", wxOK | wxICON_EXCLAMATION);
        fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password>\n");
291  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 21, 2010, 05:31:09 PM
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.
292  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 21, 2010, 04:07:57 PM
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

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".
293  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 21, 2010, 05:51:34 AM
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

...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.

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
294  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 21, 2010, 12:05:20 AM
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

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.
295  Bitcoin / Bitcoin Discussion / Re: They want to delete the Wikipedia article on: July 20, 2010, 06:38:28 PM
Bitcoin is an implementation of Wei Dai's b-money proposal on Cypherpunks in 1998 and Nick Szabo's Bitgold proposal

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 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)
296  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 19, 2010, 04:20:50 PM
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.

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?
297  Bitcoin / Bitcoin Discussion / Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower) on: July 19, 2010, 04:01:38 PM
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, 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.

The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
298  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 19, 2010, 04:43:13 AM
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?)
299  Bitcoin / Bitcoin Discussion / Re: Did block generation crawl to a halt? on: July 18, 2010, 11:35:27 PM
Nice graph!  A moving average to smooth it out would be nice. says 212 blocks in the last 24 hours, or 8.8 per hour.
300  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 18, 2010, 09:56:18 PM
Typically, over 25,000 BTC.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!