Bitcoin Forum
May 23, 2019, 10:17:49 PM *
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 »
301  Bitcoin / Development & Technical Discussion / Re: MSVC build & SHA-256 on: July 18, 2010, 09:24:09 PM
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)
302  Bitcoin / Development & Technical Discussion / JSON-RPC password on: July 18, 2010, 08:49:22 PM
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\n");
      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>
303  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.3.2 released on: July 18, 2010, 06:58:21 PM
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.
304  Bitcoin / Development & Technical Discussion / Re: URI-scheme for bitcoin on: July 18, 2010, 04:06:16 PM
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.

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.
305  Bitcoin / Development & Technical Discussion / Re: Source code documentation on: July 18, 2010, 03:12:54 PM
They're only intended for intrepid programmers who read the sourcecode.
306  Bitcoin / Bitcoin Discussion / Re: Bitcoin snack machine (fast transaction problem) on: July 18, 2010, 01:59:15 AM
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.
307  Bitcoin / Development & Technical Discussion / Re: Network Size on: July 17, 2010, 11:25:16 PM
Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.
In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.

Please upgrade to 0.3.2, it's available now.
308  Bitcoin / Development & Technical Discussion / Re: Source code documentation on: July 17, 2010, 11:18:30 PM
I didn't realize you were going to document all the intentionally undocumented commands.  They're unsupported and not intended to be used by users.

All the user-facing commands are listed in the -? help.
309  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.3.2 released on: July 17, 2010, 10:54:24 PM
However, it's important that you don't lock all the way up the very latest block.  Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.
I went about 200 blocks back.  The block chain was a clean straight line without branches, and there was only one known version of the locked block.

Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client.  Is this so?
Sorry, not yet, but I do want to make the initial block download faster.
310  Bitcoin / Bitcoin Technical Support / Re: Assertion Failure - Ubuntu Lucid on: July 17, 2010, 10:37:06 PM
My coins disappeared, but I assume they'll come back when it's up to current?
Right, they'll re-appear when it's finished downloading all the blocks.
311  Bitcoin / Bitcoin Discussion / Re: Bitcoin snack machine (fast transaction problem) on: July 17, 2010, 10:29:13 PM
I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate.  When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first.  If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:
1         0
4         1
16        4
64        16
80%      20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes.  When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends.  If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad.  A double-spent transaction wouldn't get very far without one of the listeners hearing it.  The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
312  Bitcoin / Development & Technical Discussion / Bitcoin 0.3.2 released on: July 17, 2010, 09:35:51 PM
Download links available now on bitcoin.org.  Everyone should upgrade to this version.

- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.

The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday.  (if you have this update)

I'll probably put a checkpoint in each version from now on.  Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.
313  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 17, 2010, 04:56:06 PM
0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.

But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.
314  Bitcoin / Development & Technical Discussion / Re: Privacy versus Safety: handling change on: July 17, 2010, 04:27:39 PM
We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.  They aren't very big, so it wouldn't hurt to have a lot of them.  This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.  Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.

The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.  When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.

There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.  I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
315  Bitcoin / Development & Technical Discussion / Re: BUG Report: Rounding glitch on: July 17, 2010, 04:06:12 PM
It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result.  The only place where it uses floating point to represent money is returning a value in JSON-RPC.

1.139999999999 is longer than bitcoin can internally represent.

internally, it could only be:
1.13999999 or
1.14000000

1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.

The code is this:
(double)GetBalance() / (double)COIN.

(I can't think of an easy way to fix it at the moment)
316  Bitcoin / Bitcoin Discussion / Re: A New Currency System for the World on: July 16, 2010, 10:20:09 PM
When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.
0.3.1 fixes that, sets the generate threads to the lowest priority.  Download links are on the homepage now.
317  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.3.1 released on: July 16, 2010, 09:06:57 PM
I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.

You don't need to update to 0.3.1 unless you had one of the problems listed in the first post.  If you've got it working already, stay with 0.3.0.
318  Bitcoin / Development & Technical Discussion / Sample account system using JSON-RPC needed on: July 16, 2010, 07:45:10 PM
We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system.  Most sites that sell things will need something like this.  Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.

When a user is logged in to their account, you show the bitcoin address they can send to to add funds.  Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>).  You only need to keep the latest bitcoin address for the account in your database.  (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)

You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account.  You need to keep a "debit" amount in your database.  The current balance of the account is (credit - debit).  When the user spends money, you increase debit.

If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged.  Not all sites need to wait for confirmations, so the dual current & available should be optional.  Most sites selling digital goods are fine to accept 0 confirmations.

A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address.  The sample code should be the simplest possible with the minimum extra stuff to make it a working site.

vekja.net is an example of a site like this.
319  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: July 16, 2010, 06:43:51 PM
Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour.  The time for your block to mature will always be around 20 hours.

The recent adjustment put us back to close to 6 blocks per hour again.

There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
http://nullvoid.org/bitcoin/statistix.php
320  Bitcoin / Development & Technical Discussion / Re: Website integration for bitcoin on: July 16, 2010, 06:23:04 PM
I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail.  It would be nice if you didn't have to re-invent the wheel like you're doing here.  Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.
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!