 Show Posts
|
|
Pages: « 1 2 [3]
|
|
I added label related functions to help with managing multiple addresses per user. New or renamed functions are:
getreceivedbyaddress -- amount received on a single address
getreceivedbylabel -- amount received by all addresses with this label
listreceivedbyaddress -- list addresses and amounts they've received
listreceivedbylabel -- list labels and amounts they've received
setlabel -- misc label functions for completeness
getlabel
getaddressesbylabel
For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress. The old names are still there so as not to break existing code, but they're deprecated.
The idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the "bylabel" functions. You can freely change their address without worrying about tracking all their old addresses.
A good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:
// Get a new address whenever the current one has received anything
if (strAddr == "" || getreceivedbyaddress(strAddr) > 0)
strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address
// Get total received by all the user's addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance
If you're just getting one particular user's balance, such as in response to a page request by that user, use getreceivedbylabel, but if you're scanning over all users, it's better to use listreceivedbylabel to get the complete list and scan against the result. Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).
You should only really need to scan all users if you're polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it. It's not necessary to poll very frequently. If you require 1 confirmation, that'll take an average of 10 minutes anyway, so there's no point in polling more often than every few minutes.
If you're selling digital goods and services, where you don't lose much if someone gets a free access, and it can't be resold for profit, I think you're fine to accept 0 confirmations.
It's mostly only if you were selling gold or currency that you'd need multiple confirmations.
|
|
|
|
|
When you want to upload an image to embed in a forum post, there are services like imageshack, but because they're free, they limit the number of views. It's a minuscule amount of bandwidth cost, but they can't just give it away for free, there has to be something in it for them. It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.
It's worse if you want to upload a file for others to download. There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.
It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins. Anyone with some extra bandwidth quota could throw it on their webserver and run it. Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles. Ideally, it should be MIT license or public domain.
Services like this would be great for anonymous users, who have trouble paying for things.
|
|
|
|
New icons, what do you think? Better than the old one?     Full size 530x529 image for scaling down to custom sizes: http://www.bitcoin.org/download/bitcoin530.pngThe perspective shadow was too thick on the larger sizes. I updated 32, 48 and the full size. I release these images into the public domain (copyright-free). I request that derivative works be made public domain. |
|
|
|
|
Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC.
On Linux it needs libgtk2.0-0 installed, but does not need a GUI running. Hopefully gtk can be installed without having a windowing system installed.
The command to start as a daemon is:
bitcoin -daemon [switches...]
Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the "-server" switch.
bitcoin -server [switches...]
With either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332. The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it's running under.
To control it from the command line, the interface is a command name without any switches, followed by parameters if any.
bitcoin <command> [params...]
For example:
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop
It's a simple JSON-RPC client and prints the JSON result. Look at rpc.cpp for the list of commands.
Web apps or anything automated will normally use JSON-RPC directly, not command line. There are JSON-RPC libraries for all the major languages. In script languages like PHP and Python the syntax is as natural as calling a local function.
|
|
|
|
|
Uploaded some UI changes to SVN as version 0.2.5.
Instead of View->Show Generated, we now have tabs:
- All Transactions
- Sent/Received
- Sent
- Received
Makes it a lot easier to flip to received and check for payments.
Moved the "Your Addresses" book inside the main address book. It was confusing having two address books.
I found the "To:" in "From: unknown, To: (one of your bitcoin addresses)" still confusing, so I changed it to "From: unknown, Received with:". The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book.
Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.
I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing.
|
|
|
|
|
It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works. If you can accept incoming connections and you have a static IP address, post it here!
Anything sent to these IPs should be considered a donation.
If you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it'll be one-way. They won't necessarily be watching for incoming transactions to send back.
|
|
|
|
Thank you for the offer to help translate. That is probably the best way you could help. I will need to prepare the code for translation first. wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard. We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support. I've done test builds with 2.9.0 and there is one bug left to fix. What operating system are you using? Windows, Linux 32-bit or 64 bit? Split from another thread.
sirius-m |
|
|
|
|
We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.
The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that. For most of last year, we were hovering below the minimum. On 30 Dec we broke above it and the algorithm adjusted to more difficulty. It's been getting more difficult at each adjustment since then.
The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year. That means you generate only 55% as many coins for the same amount of work.
The difficulty adjusts proportionally to the total effort across the network. If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.
For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log. It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block. It gets adjusted every 2016 blocks, typically two weeks. That's when it prints "GetNextWorkRequired RETARGET" in debug.log.
minimum 00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000
date, difficulty factor, % change
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
05/08/2010 352.17 +44%
15/08/2010 511.77 +45%
26/08/2010 623.39 +22%
|
|
|
|
|
We've been working hard on improvements for the next version release. Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout
- Setup EXE for Windows, in addition to the archive download
I've been working on a number of refinements to the networking code and laying the groundwork for future functionality. Also coming in version 0.2:
- Multi-processor support for coin generation
- Proxy support
|
|
|
|
|
--------------------
scott:
Linux/UNIX compile
Posted:Thu 08 of Oct, 2009 (05:49 UTC)
Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great.
|
|
|
|
|
--------------------
bitcoinbitcoin:
How anonymous are bitcoins?
Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?
|
|
|
|
|
--------------------
anonguy54:
Request: Make this anonymous?
Posted:Thu 15 of Oct, 2009 (19:58 UTC)
Are there any plans to make this service anonymous?
e.g; Being able to route BitCoin through Tor.
|
|
|
|
|
--------------------
bitcoinbitcoin:
Bitcoin Maturation
Posted:Thu 01 of Oct, 2009 (14:12 UTC)
From the user's perspective the bitcoin maturation process can be broken down into 8 stages.
1. The initial network transaction that occurs when you first click Generate Coins.
2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.
Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?
--------------------
sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)
As far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating the next proof-of-work. The CPU usage is 100% when you're generating coins.
In this example, the network connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.
|
|
|
|
|
