Bitcoin Forum
May 25, 2019, 10:38:45 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 »
381  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: July 02, 2010, 09:57:45 PM
(reverted to rc2)

Links removed, 0.3 is now released, so go to to download it.
382  Bitcoin / Development & Technical Discussion / Re: 1.3 almost ready on: July 02, 2010, 08:37:17 PM
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow.
383  Bitcoin / Development & Technical Discussion / Re: Feature Request: Limiting Connections on: July 02, 2010, 07:21:36 PM
Thanks for the feedback on this.

One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5.  The choice of 15 was arbitrary.  It just needs to be enough for redundancy and fast exponential propagation of messages.  10 would still be plenty.  5 should be fine.  10 is good as a nice round number so users can see that it stopped intentionally.

It would help to implement UPnP so there would be more inbound accepting nodes.  Your number of connections is the ratio of inbound accepting nodes to out-only times 15.  We need to encourage more people to accept inbound connections.

I will implement a feature to stop accepting inbound connections once you hit a certain number.

Which version are you running?

Anyone know how many connections typical P2P software like BitTorrent can get up to?

384  Economy / Economics / Re: Major Meltdown on: June 27, 2010, 07:06:09 PM
Here's an answer to a similar question about how to recover from a major meltdown.

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in an orderly way.  The software would be programmed to start using a new hash after a certain block number.  Everyone would have to upgrade by that time.  The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
385  Bitcoin / Development & Technical Discussion / Re: 1.3 almost ready on: June 27, 2010, 03:30:13 PM
MinGW still only has good old stable 3.4.5.  There's not much reason for them to update it.

When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all.  I can't imagine how 8% more could be squeezed out of it.  Is it possible Windows could have 8% more overhead?  Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
386  Bitcoin / Development & Technical Discussion / Re: IPv6, headless client, and more on: June 27, 2010, 01:02:38 PM
Welcome, Harry.

I hadn't thought about starting out using bitcoind without using bitcoin first.  I guess for now, this thread serves as the tutorial. 

The focus for bitcoind so far has been more on backend support for websites.  There's demand for things that would be nice for adminning headless generators like listgenerated.  For the moment, you can grep the debug.log file for "generated" and "hashmeter" for some feedback.  Generated blocks take about 24 hours before they're credited to your balance.
387  Bitcoin / Development & Technical Discussion / Re: Beta? on: June 27, 2010, 12:43:50 PM
But 1.0 sounds like the first release.  For some things newness is a virtue but for this type of software, maturity and stability are important.  I don't want to put my money in something that's 1.0.  1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started.  This is the third major release and 1.3 reflects that development history.  (0.1, 0.2, 1.3)
388  Economy / Marketplace / Re: Bitcoin Faucet changes on: June 26, 2010, 09:39:52 PM
Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?).  Maybe you should have a minimum time between payments per class-B.

If you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha.
389  Bitcoin / Development & Technical Discussion / Re: Building BitCoin Client completely Headless on: June 26, 2010, 09:06:06 PM
The linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind.
390  Bitcoin / Bitcoin Discussion / Re: Bitcoin mobile. on: June 26, 2010, 08:58:26 PM
You can of course use services like or on a mobile browser, depositing money there to the extent you trust them.
I think that's the best option right now.  Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.

They could make a smaller version of the site optimized for mobile.  If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.

If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis?  It could always be an Android app instead.  An app is not really necessary though, just a mobile sized website.

A web interface to your own Bitcoin server at home wouldn't be a solution for everyone.  Most users don't have a static IP, and it's too much trouble to set up port forwarding.
391  Bitcoin / Development & Technical Discussion / Re: 1.3 almost ready on: June 26, 2010, 07:21:05 PM
Changed the version number to 1.3 and removed "Beta".

(links removed, see below)

392  Bitcoin / Development & Technical Discussion / Beta? on: June 26, 2010, 05:02:43 PM
Is it about time we lose the Beta?  I would make this release version 1.3.
393  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 26, 2010, 03:10:10 PM
The first panel of the status bar is shared with the help description of menu items as you hover over them.  Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
394  Bitcoin / Bitcoin Discussion / Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel on: June 26, 2010, 02:28:06 PM
Freenode is too visible, right in the middle of where all those users and moderators are hanging out.  Laszlo's option is a much better fit for us.

I made 0.3.0.RC2 available that uses instead of freenode if you want to start switching over:
395  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 26, 2010, 12:32:09 AM
Lets try using Laszlo's instead of freenode.  Here's RC2, that's the only change in it:

(see below for download links)
396  Bitcoin / Development & Technical Discussion / Re: On IRC bootstrapping on: June 25, 2010, 10:40:47 PM
I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything.  It is only two servers right now but we don't mess with it or anything, it just runs.

My box is a dedicated irc server:
 2:28PM  up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08

You can use to connect.
This seems like a good idea.

What does everyone think, should we make the switch for 0.3?
397  Bitcoin / Bitcoin Discussion / Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel on: June 25, 2010, 09:15:15 PM
We need more details about what happened MadHatter.

Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected.

0.2 can find other nodes without IRC if it's ever been connected before, but a new install can't discover the network for the first time without IRC.

0.3 can also seed without IRC.  It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy.
398  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 25, 2010, 02:10:06 PM
Thanks virtualcoin, that's a perfect comparison.

The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).

The 15% speedup from 32-bit to 64-bit Linux is more of a mystery.  The code is completely 32-bit.

Hmm, I think the 8 extra registers added by x86-64 must be what's helping.  That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
399  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 25, 2010, 02:17:41 AM
I don't know.  Maybe someone with more Linux experience knows how to install the library it needs.

I built it on Ubuntu 10.04.  I hope that wasn't a mistake.  Maybe it should have been built on an older version for more backward compatibility.  Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions?  Is there any way I can downgrade to an older version of GCC on 10.04?

The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check.  SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.

We don't need to bother with a 64-bit version for Windows.  32-bit programs work on all versions of Windows.  It's not like Linux where the 64-bit OS wants 64-bit programs.

I'm also curious if it's a little faster on linux than windows.

Do you think I should make the directories:
instead of
400  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 24, 2010, 05:40:05 PM
Here's RC1 for linux for testing:
(link removed, see below)

It contains both 32-bit and 64-bit binaries.

Recent changes:

- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.

- The libboost libraries have removed the "-mt" from their filenames in 1.40.  If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
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!