analzye the text- "'s go.
", i don't think we should implement listtransactions.
"./bitcoin: /lib64/libc.so.6: version `glibc_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it?
":" is a candidate, but ipv6 has : in it and that might get confusing.
"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.
"get it at http://www.bitcoin.org or read the forum to find out more."
"give me a bitcoin to receive a payment with".
"group signatures" may be related.
"it said 7 days and i waited more than a week and didn't get anything!"
"member activation when this option is enabled any members registering to the forum will have a activation link emailed to them which they must click before they can become full members" i think that's the only way to make sure the forum can't be used to send to other people's e-mail addresses and potentially use it to spam.
"minimize to the tray instead of the taskbar" & "minimize to the tray on close" must not be implemented yet on the mac.
"natural deflation"... i like that name for it.
"please send x bc to [single-use bitcoin address] to complete your order"  when the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.
"send x bitcoins to my priority hotline at this ip and i'll read the message personally."
"transaction filter tabs" sounds better.
# access this project's databases over the internet we shouldn't try to use security against identity theft as a selling point, since it leads into these counter arguments.
# seems more clear key some full sentence with spaces in it.
# than this allright then, lets go with self-parsed mapconfig, syntax: file extension .conf.
# user who likes column formatted this sentence would be this    # "this sentence would be this" guess this is ok too the normal syntax should be "key=value", but you can't blame people for the occasional "key = value".
%appdata% is per-user access privilege.
(--enable-debug --disable-shared --enable-monolithic) the download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time.
(0.1, 0.2, 1.3) many big isps give you a new ip every time you connect, usually in the same class b (a.b.?.?).
(0.1.5 doesn't have -min so it would be an open window) to only run a seed: bitcoin -min -gen=0 you could sort of monitor it by looking at debug.log.
(120 conf / 6 blocks per hour = 20 hours)  that's the normal length of time before you can spend it.
(about 7 bytes for flags and 12 bytes for possible future ipv6 expansion) the larger things we have like blocks and transactions can't be optimized much more for size.
(all we really need is disable the forum's access to the mail server) right, forgot about that.
(although, keep licensing in mind)  the one we have is the only one i tried, so there's significant chance for improvement.
(and anyone else with 64-bit amd)  and what amd chip do you have?
(and maybe that's what it said and i forgot and spread 500 to all error responses) obviously it's a bug that it repeats the header.
(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?)
(apache2ctl graceful) the bitcoin.org dns change went through about 12 hours ago.
(at least with gcc or msvc) i uploaded 0.3.8.1 for linux with re-built 64-bit.
(available by request at the moment, full release soon) right, it's ecc digital signatures.
(by creating a transaction sending the money to yourself with the stronger sig) i'll start thinking about how to do this.
(debit a, credit b)  i can't imagine they're required to batch all their stuff up themselves.
(edit: or at least i assume so, that's how the world usually works, but maybe wiki is different) so you drop a settings file in the ~/.bitcoin directory, that sounds better.
(even if it's rather simple and boring)  is the file listed always blkindex.dat, or does it include addr.dat or wallet.dat too?
(even if only within europe) is there any way to find out what the missing shared libraries are?
(gcc symbols for gdb, if you're using msvc i can send you an msvc build with symbols) thanks for your help!
(hope you don't mind i renamed your thread, sha-256 optimisation is something important that i keep forgetting about) i uploaded to svn my changes to add a password to json-rpc.
(i can't think of an easy way to fix it at the moment) 0.3.1 fixes that, sets the generate threads to the lowest priority.
(i don't have an i5 or amd)  if it checks out, i'll put together the full package and do all the release stuff.
(i don't know xunie, but he hasn't posted for months and he was a goofball) thanks, did you finish moving bitcoinexchange to another server?
(i haven't tested this yet)  it checks all the blocks in the main chain.
(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.
(i said something earlier about nat port translation, but that wouldn't work, other nodes wouldn't know to connect to that port) if you want, as a small optimization, you could run the rest of your computers as: bitcoin -connect=<the ip of the first computer> so they get all their network communication from the first computer and don't all connect over the net individually for the same information.
(i should print the test version in the log) that's great, this is going to fun!
(i would definitely want some)  maybe collectors, any random reason could spark it.
(i'm using the word scarce here to only mean limited potential supply) bitcoins have no dividend or potential future dividend, therefore not like a stock.
(i've been meaning to edit the homepage) "the developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government."
(if it works fine after that, you can delete them later) i'm reluctant to make the installer delete or move those files.
(if it's not, then it should be fixed)  that's the only case where you would use byte reverse.
(if you get anything, we need to keep private for him the fact that we got a donation) please promise me you won't make a switch now.
(if you have this update) i'll probably put a checkpoint in each version from now on.
(if your response is an argument that there's no benefit at all, i guess that will reinforce the case that people won't be able to understand it.)
(in the status bar) you should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again.
(inflation issues were superseded by changes i made later to support transaction fees and the limited circulation plan.
(is that text good enough or any improvements?)
(it automatically does what the sample code i posted some time ago did) would these commands make it possible in simple cases to implement your website without needing a database of your own?
(it can't change pindexbest without actually doing a reorg) this isn't perfect yet.
(it'll be in init.cpp) sorry about my choice of the filename "main.cpp", another possible name would have been "core.cpp".
(json-rpc is fine)  still under construction.
(let me know if that compiles now) it was able to reproduce this.
(like 5 seconds) no, it doesn't usually empty your wallet with each transaction.
(links removed, see below) uses irc.lfnet.org.
(many light changes don't require understanding the language to fix the translated pages) it‚Äôs recommended that you stop bitcoin before backing it up to make sure the backup will be correct."
(multiple invocation is probably almost never used anyway) i also fixed the two duplicated commands listed in the help: t i thought too.
(now it's renamed to listreceivedbyaddress 0)  the default is 1 confirmation, but i think in reality most digital goods and services can be 0 confirmations.
(o(n) vs o(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker) i'm doing something like that.
(on a side note, i read that the record companies would like to dos all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)
(or if you'd rather get upgrading out of the way now instead of waiting) linux please test rc2 instead.
(or maybe because tcatm had an amd and optimised his code for that) there's been so much else to do that i haven't had time to make -4way automatic.
(or you could pm me here) please upgrade to 0.3.3!
(replace your blk0001.dat and blkindex.dat files) 3) upgrade.
(search on getreceivedbylabel or getnewaddress)  the sample code could be a plain vanilla bank site where you can deposit and send payments.
(see db.log also)  now that the zombie problem is fixed in test5, could you start running it on your linux machine?
(see it's about to increase again in a few hours.
(sometimes the one you run was the best when you started but you found better ones later) lr and pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between bitcoin and lr/pecunix would give us 2nd-hop access to all that.
(sudo apt-get install ia32-libs)  if we made a debian package, it could automatically pull that in as a dependency.
(thanks to gavin andresen) - json-rpc command line returns exit codes.
(that was the only use of mapaddresses.count) if you could try this version and confirm that the crash is fixed, i'd appreciate it.
(the stack trace doesn't always go far enough back unfortunately) ok, so no crash or exception window or anything.
(they're redistributable well this doesn't look good.
(to figure the % increase) you figured it out faster than i could post a reply.
(was it obvious you can doubleclick on a line for details?)
(what library was he using?)
(with firefox) i know this sounds really retarded, but i still haven't been able to get the sourceforge login page to load, so i haven't been able to read it either.
(with version 0.1.5 you'd have to copy the whole "%appdata%/bitcoin" directory.)
), concatenate them into a string and pass it to json, so you could go: boost has boost::program_options.
), it'll retry with a non-address random username.
* files can normally be deleted safely.
* files only contain temporary database data.
* files that are not compatible with ours.
**warning: this will block the gui."
+1 any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.
+1 theymos.
+1 to you for having such a long password that you found this bug.
- added a simple security safeguard that locks-in the block chain up to this point.
- added some dos controls as gavin and i have said clearly before, the software is not at all resistant to dos attack.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- extranonce not needed.
- french translation by aidos.
- get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do: - make a subdirectory under src: locale/?
- hash1 is always the same, but included for convenience.
- json-rpc "backupwallet" command.
- logging of "threadrpcserver method=getwork" is disabled, it would be too much junk in the log.
- make the money handling methods of the json-rpc interface return an error.
- microsoft security essentials.
- multi-processor support for coin generation - proxy support for use with tor - fixed some slowdowns in the initial block download - various refinements to keep the network running smoothly we also have a new forum at http://www.bitcoin.org/smf/ if you have any questions.
- multi-processor support for coin generation - proxy support for use with tor - fixed some slowdowns in the initial block download major thanks to martti malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and new liberty standard for his help with testing the linux version.
- multi-processor support for coin generation - proxy support for use with tor - fixed some slowdowns in the initial block download we also have a new forum at http://www.bitcoin.org/smf/ many thanks to martti (sirius-m) for all his development work, and to new liberty standard for his help with testing the linux version.
- no mint or other trusted parties.
- participants can be anonymous.
- recovers and continues if an exception is caused by a message you received.
- reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- removed "safe mode" alerts "safe mode" alerts was a temporary measure after the 0.3.9 overflow bug.
- removed "safe mode" alerts.
- spanish translation by milkiway.
- state renamed to midstate for consistency.
- the "backupwallet <destination>" command that was discussed in another thread.
- the block field has been separated into data and hash1.
- the block field has been split into data and hash1.
- the package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- unpack the files into a directory - run bitcoin.exe - it automatically connects to other nodes if you can keep a node running that accepts incoming connections, you'll really be helping the network a lot.
- updated version numbers.
- warning not to mess around with your wallet.dat file.
-- i am definitely not making an such taunt or assertion.
-- that's not really something i meant to say publicly.
-4way should eventually be replaced by an auto-detect.
-checkblocks does more, but is still easily defeated.
-connect will allow you to connect to non-routable addresses like 192.168.x.x.
-lwx_gtk2ud-2.9 only matches the right configuration.
-paytxfee allows you to include a transaction fee with your transactions.
-paytxfee=0.01 this is in svn rev 130.  check that it compiles right.
// if you make a sale, move the money from their account to your "" account sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user") you can use listtransactions(username) to show them a list of their recent transactions.
0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.
0.01 is basically a proof of work, but not wasted.
0.1.5 actually had an option to set that, but i took it out to reduce confusion.
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.2 has code to make sure it goes smoothly.
0.2.5 has a "new..." button next to it to make it easy to change each time you use it.
0.3 can also seed without irc.
0.3 released announcing version 0.3 of bitcoin, the p2p cryptocurrency!
0.3.10 has tcatm's 4-way sse2 as an option switch.
0.3.13 rc1 is available for windows: true, the switch should be something more dynamic that pays per kb.
0.3.13 release candidate, to be released soon so please test: - don't count or spend payments until they have 1 confirmation - internal version number from 312 to 31300 - only accept transactions sent by ip address if -allowreceivebyip is specified - dropped db_private berkeley db flag - fix problem sending the last cent with sub-cent fractional change - auto-detect whether to use 128-bit 4-way sse2 on linux gavin andresen: - option -rpcallowip= to accept json-rpc connections from another machine - clean shutdown on sigterm on linux 0.3.13 release candidate, please test: as you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation.
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%.
0.3.6 linux build is back to the old makefile.unix.
0.3.9 and lower nodes have been responding with the current block number for some hours now.
0.3.9 and lower nodes still must upgrade.
0/unconfirmed transactions are very much second class citizens.
1) during generation (when the status bar says "generating" and you're using cpu to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block.
1) if (strrpcpassword.size() < 15) sleep(50);  -- this means if it's a short password, it'll wait 50ms after each attempt.
1) ip records don't need to be in the chain, just do registrar function not dns.
1) menu bar default color.
1) once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
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.
1.139999999999 is longer than bitcoin can internally represent.
10 is good as a nice round number so users can see that it stopped intentionally.
10 would still be plenty.
127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's ok because it would only serve the convenience function of pre-filling the fields in a dialog.
15 was a lot more than needed.
15 was way more than we needed for redundancy.
2 seconds of latency in both directions should reduce your generation success by less than 1%.
2) balance bar not a different color.
2) begin = strrequest.end();  -- if it's a single request with multiple invocations, i throw away the rest if one has a bad password.
2) delete (or move) blk*.dat 3) upgrade to 0.3.10.
2) download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.
2) download knightmb's blk files.
2) each node collects new transactions into a block.
2) if you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.
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.
2) pick one tld, .web +1.
2) show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.
2) switch the bitcoin.org dns entry.
2) the merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address.
2) when there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
2) when you successfully generate a block, it is immediately broadcast to the network.
2.8 has two build variations, ansi and utf-16 (unicode).
2.8.10 or 2.9.0 are probably fine though.
2.9 has only one version, utf-8.
24 cores should get 66,000khps.
2^80 is if you can use a birthday attack.
3) a transaction can be replaced by a double-spend with a different txid.
3) background behind bitcoin address and balance now the same color as toolbar.
3) each node works on finding a difficult proof-of-work for its block.
3) expiration and significant renewal costs, very important.
3) keep working on the drupal site behind the scenes.
3) nothing, if sending by bitcoin address 5) it is decentralised.
3) upgrade to 0.3.10.
30khash increase to what total rate?
31300 > 312. i would not encourage using the extra decimal places.
32-bit programs work on all versions of windows.
33% faster with hyperthreading than without it.
4) after google has had time to update its records, we can switch over to the drupal site.
4) it redownloads all blocks, probably take about an hour.
4) it should start out with less than 74000 blocks and redownload the rest.
4) it should start out with less than 74000 blocks.
4) when a node finds a proof-of-work, it broadcasts the block to all nodes.
45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node.
5 btc seems like a lot these days, maybe the normal amount should be 1 or 2 btc.
5 should be fine.
5) nodes accept the block only if all transactions in it are valid and not already spent.
6 chars = 3 difficulty 7 chars = 410 difficulty 8 chars = 25418 difficulty +1 even with encryption, a trusted storage place is better.
6) nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
64-bit wouldn't make it any faster, since it uses 64-bit numbers in only a few places and sha-256 is a 32-bit algorithm, but it may be convenient for those running a 64-bit os.
8 is still plenty for redundancy.
8 is still plenty of redundancy.
8-bit, 16-bit, 24-bit, 32-bit, what is it?
80 bytes per header and no indexing work.
: creighto: i agree with that idea.
<pubkey> can be 33 to 120 bytes.
<pubkey> op_checksig.
?/lc_messages (??
?499 and ?
?999.
@dtvan: all 3 excellent points.
@theymos: if nothing else, we can fall back on that solution in the future.
[1] during hunt's accumulation of the precious metal silver prices rose from $11 an ounce in september 1979 to nearly $50 an ounce in january 1980.
[2] silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as silver thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.
[3]" i think i see where the problem is.
[again, i don't know why i'm including this, as it's best to stay away from claims about spam.
[data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed.
[i've been asked at least 4 other times "have you heard of ripple?"]
[in response to a question about scale] 100,000 block generating nodes is a good ballpark large-scale size to think about.
[includeempty] whether to include addresses that haven't received any payments.
[note: i have some improvements in 0.1.6 to reduce this problem somewhat, and it'll also improve when the network is larger] transactions sent to a bitcoin address will always say "from: unknown".
[question about what to backup] the crucial file to backup is wallet.dat.
[question about what to backup] the directory is "%appdata%\bitcoin" it has spaces in it so you need the quotes on xp it would typically be: backup that whole directory.
[question about what to backup] the files are in "%appdata%\bitcoin", that's the directory to backup.
[this inflation discussion was before the transaction fee mechanism and fixed plan of 21 million coins was posted, so it may not be as applicable anymore] you're still thinking as if the difficulty level will be so easy that people will be able to generate all the bitcoins they want.
[this next bit turned out to be very controversial.
a basic transaction is just what you see in the figure in section 2.  a signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.
a bitcoin address must be kept to show ownership of anything sent to it.
a block header with no transactions would be about 80 bytes.
a blockindex may have multiple pprev pointing back to it, but pnext will only point forward to the longest branch, or will be null if the block is not part of the longest chain.
a c++ implementation is under development for release as an open source project.
a certain percentage of fraud is accepted as unavoidable.
a client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent.
a common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending.
a computer that's half as fast would get half as many coins.
a digital coin contains the public key of its owner.
a discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.
a domain object could entitle you to one domain, and you could change it at will to any name that isn't taken.
a double-spent transaction wouldn't get very far without one of the listeners hearing it.
a drawback would be that the status numbers shown by different nodes would not match.
a few details: the faq says "see section 2.3", but the sections aren't numbered.
a few lines of code could create a transaction with an extra hash in it of anything that needs to be timestamped.
a few more things and i'll upload it.
a first patch will be in svn rev 132.  it's not uploaded yet.
a generation ago, multi-user time-sharing computer systems had a similar problem.
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 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.
a key aspect of bitcoin is that the security of the network grows as the size of the network and the amount of value that needs to be protected grows.
a key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.
a lighter option would be a special case only if all confirmations are your own.
a little follow up when the software was released.
a little late, but in case anyone else has the same issue.
a lone node in a class c will get as much attention as someone holding all 255 ips in another class c. choose a random class c organize all addresses in the class c by ip choose a random ip in the class c once we've chosen an ip, we'll try every given port before moving on advertise our address get as many addresses as we can should the one on the receiving end do this too?
a longer interval than 10 minutes would be appropriate for bitdns.
a lot of the core interest in bitcoin is going to be from the privacy crowd.
a lot of times you just need a minuscule amount of online currency.
a lot of your hits will usually be from the same people.
a memory leak debug tool could give a clue.
a more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1: and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
a more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected.
a moving average to smooth it out would be nice.
a new generated bitcoin address would be sent through the ssl connection.
a new key pair is used for every transaction.
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.
a normal one shows 17mb memory usage and 10mb vm size.
a payee can verify the signatures to verify the chain of ownership the problem of course is the payee can't verify that one of the owners did not double-spend the coin.
a purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
a quick summary: my system went from ~7100 to ~4200.
a rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases.
a revised version of getwork is now in the official client, but the miners need to be updated a little to use it.
a rough back-of-the-envelope example: so if a double-spend has to wait even a second, it has a huge disadvantage.
a second version would be a massive development and maintenance hassle for me.
a simplistic way would be to disable "pframemain->show" and "ptaskbaricon->show" in ui.cpp.
a solution may be for just one of the networks if one network has a lower difficulty.
a somewhat old one is better so it can download and verify the most recent blocks.
a subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation".
a thief usually needs a high probability of getting an item for free to make it worthwhile.
a timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or usenet post [2-5].
a transaction can be written that requires two signatures to spend it next.
a transaction can contain multiple inputs and outputs.
a transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount.
a transaction over the size limit can still be sent if a small fee is added.
a user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the merkle branch linking the transaction to the block it's timestamped in.
a wallet merge tool is possible to implement but much less in demand once resync solves most of the problem.
a web interface to your own bitcoin server at home wouldn't be a solution for everyone.
a week later.
about 1.5 days to go until the next one.
about how long did it take to start?
actually, "tabs for sent and received transactions" sounds really immature if it doesn't have that already.
actually, it works well to just pm me.
actually, msvc 6.0's runtime (msvc60.dll) is the last version that shipped preinstalled on windows, which is why the continued interest in that ancient version of the compiler.
actually, please try this instead, this is more correct: comparing unsigned int -1 (0xffffffff) with long unsigned int -1 (0xffffffffffffffff) results in the unsigned int being promoted to 64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff.
actually, that is handled.
adam back (hashcash.org) noticed the similarities and pointed me to your site.i need to find out the year of publication of your b-money page for the citation in my paper.
add to block index without updating disk precompute tree structure test mapnext[pindex->pprev].push_back(pindex); print split or gap print columns print item put the main timechain first iterate children size limits check timestamp check proof of work matches claimed amount first transaction must be coinbase, the rest must not be check transactions check merkleroot check for duplicate get prev block index check timestamp against prev check proof of work check transaction inputs and verify signatures write block to history file add atoms to user reviews for coins created check for duplicate preliminary checks if don't already have its previous block, shunt it off to holding area until we get it ask this guy to fill in what we're missing store to disk now process any orphan blocks that depended on this one messages don't know what it is, just say we already got one message format (4) message start (12) command (4) size (x) data scan for message start read header message size rewind and wait for rest of message need a mechanism to give up waiting for overlong message size error copy message to its own buffer process message can only do this once ask the first connected node for block updates must have a version message before anything else store the new addresses put on lists to send to other nodes send block from disk send stream from relay memory find the first block the caller has in the main chain send the rest of the chain find the owner's new transactions upgrade transaction to a fully supported cwallettx debug print need to expand the time range if not enough found int64 nsince = getadjustedtime() - 60 * 60; in the last hour we have a chance to check the order here keep giving the same key to the same ip until they use it send back approval of order and pubkey to use broadcast send back confirmation ignore unknown commands for extensibility don't send anything until we get their version message message: addr message: inventory message: getdata bitcoinminer create coinbase tx cbignum bnnonce; this nonce is so multiple processes working for the same keyuser bn_rand_range(&bnnonce, &cbignum(int_max));  don't cover the same ground create new block add our coinbase tx as first transaction collect the latest transactions into the block find if all dependencies are in this or previous blocks if (ntransactionfee < 0) could require a tx fee here add tx to block update last few things prebuild hash buffer get time of previous block search debug print process this block the same as if we had received it from another node update ntime every few seconds actions list of values less than target solve subset sum by stochastic approximation if the next larger is still closer, return it choose coins to use fill vout[0] to the payee fill vout[1] back to self with any change use the same key as one of the coins fill vout[1] to ourself fill vin fill vtxprev by copying from previous transactions vtxprev add tx to wallet, because if it has change it's also ours, otherwise just for transaction history.
adding command line support is a high priority.
adding more transactions to the block you're working on does not slow down your generation rate.
adding to that, every time you move your mouse inside the bitcoin window you're generating entropy, and entropy is captured from the timing of disk ops.
additional languages can be added to an existing program by adding .mo files without recompiling the program.
afaik, the only e-mail is if you tell the forum to do notifications, and i guess the wiki registration.
after a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent.
after a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance.
after a year, you could generate 12 cents.
after each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
after it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block.
after that it's just one line to send the combined unit.
after that, the increasing #/confirmed number is just monitoring the outcome.
after that, whether it's able to make some good connections, or sockets is completely hosed and it stays at 0 connections, i don't know.
after the first 50kb sells out, the price is raised to 0.01.  after 250kb is sold, it goes up to 0.02.  at some price, you can pretty much always get in if you're willing to outbid the other customers.
after working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.
after you have connected to the network the first time, you no longer need irc.
after you upgraded to 0.1.2, your node responded to one or two messages and then stopped replying to messages.
again, keep it short.
aggregators would set up shop to buy bitcoins in smaller increments, which would add confidence in users ability to sell bitcoins if there are more available buyers than just you.
agree, wanted to do that for a long time, haven't had time to do it.
agree.
ah yes, there we go, back to normal again.
alert messages are signed with a private key that only i have.
alerts are broadcast through the network and apply to a range of version numbers.
all 21 connection attempts were to a node with version 31300 (0.3.13).
all but one of your node connections went dead at the same time, one shortly after.
all commands now require the password as the first parameter.
all communications with the network are broadcasts of public information.
all data files are in that directory.
all data is stored in the .dat files.
all it needs to do is not create the main window.
all modern cpus save power when they're idle.
all nodes keep running and generating, the network stays up.
all the places where address book labels are set are where the user manually sets it.
all the transaction fees would be additional transactions.
all the user-facing commands are listed in the -?
all this is fine for ui code, since this is the same constraint placed by windows anyway, but for ui-less server daemon code, wx calls are uncertain.
all those factors multiply together.
all transactions, ip changes, renewals, etc.
all versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
all you have to do is get poedit and translate the po file i'm attaching to this post.
all you should see is that your number of confirmations starts over from 0. in some types of forks, your transaction would have gotten into both forks already, so you're already good either way.
all your own data is stored in wallet.dat.
all your sockets went dead somehow.
almost all transactions are free.
almost but not quite.
already does that.
also coming in version 0.2: multi-processor support for coin generation proxy support the linux version is on its way.
also in 0.3.6, faster hashing: - midstate cache optimisation thanks to tcatm - crypto++ asm sha-256 thanks to blackeye total generating speedup 2.4x faster.
also in svn rev 147: - the command line json-rpc returns the error code as its exit code.
also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.
also, anonymous sounds a bit shady.
also, could you delete the last sentence on the faq "they are planned to be hidden in v0.1.6, since they're just confusing and annoying and there's no reason for users to have to see them."
also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and blackeye's help getting asm sha-256 working.
also, even if using rsa for messages, it would still make sense to do all the bitcoin network with ecdsa and use rsa in parallel for only the message part.
also, i'm adding code to verify the block index, which means the proof-of-work chain is checked.
also, it would suck to be on a smaller, less reliable host just to save a measly $20.
also, the recipient needs to be synced up with the block chain before it'll see the received transaction.
also, there was some advice on the web that prio_process is used on linux because threads are processes.
although i am worried about liberty's wine crashes.
although it would be possible for bitcoin to take care of business in the http response by presenting html ui to the user, as a user i would wonder if some website is trying to trick me or if i'm really talking to my own bitcoin server.
although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer.
although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.
am i missing something?
amd is the best choice because it has the best sse2 implementation.
amd phenom (i think 4-core) cpus are doing about 11,000khps with -4way, about 100% speedup.
an analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision.
an app is not really necessary though, just a mobile sized website.
an attack that could so thoroughly vanquish sha256 to bring it within computationally tractable range has a good chance of clobbering sha512 too.
an attacker can only try to change one of his own transactions to take back money he recently spent.
an attacker would only have to break the hash function, not ecdsa.
an early accounts patch or git build?
an example of a site running the software: what do you think?
an output of a transaction.
and ca problem solved, neat.
and makes most rpc commands return an error.
and maybe some explanation about why you shouldn't reuse addresses.
and the no-priority-requirement area is 3k, about a dozen transactions per block.
and yes, he wants to remain anonymous, so please keep the envelope's origin private.
announcing the first release of bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending.
announcing the release of bitcoin, a new open source peer-to-peer electronic cash system that's completely decentralized, with no central server or trusted parties.
announcing version 0.3 of bitcoin, the p2p cryptocurrency!
another factor that would mitigate spam if pow tokens have value: automated mailboxes that collect their pow and don't read the there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest pow tokens from spam.
another factor that would mitigate spam if pow tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest pow tokens from spam.
another feature for later is an option to encrypt your wallet.
another issue i thought of with zetaboards: most free forum sites won't let you export the user account database if you want to move.
another line of thought is that it should be like a bank website, stately, professional and official looking to support confidence in financial matters.
another option is to search the world again for an irc server that doesn't ban tor nodes.
another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes.
another problem is that tor users can't accept incoming connections, and we have so few that can.
another solution is to use ssl.
another way they can become more practical is if i implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.
another way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it's doing.
any blocks in the bad chain wouldn't have matured yet.
any class c (a.b.c.?)
any fiat currency typically averages more inflation than that.
any generated blocks would probably not be accepted since you can't broadcast them and other nodes will leave your branch behind.
any hard limits that„Ç‚†prevent people from„Ç‚†using bitcoin as frequently as they want to„Ç‚†should not exist.
any ideas where we can get a free forum?
any ideas?
any larger than that looks bad.
any later double-spends are immediately rejected once there's already a spend in the main chain.
any mac code should only use __wxmac_osx__, not __wxmac__ or __wxosx__, and we should stop using __bsd__.
any needed rules and incentives can be enforced with this consensus mechanism.
any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone.
any owner could try to re-spend an already spent coin by signing it again to another owner.
any portscan would only get a dead connection that doesn't volunteer to identify itself.
any problems you find in the linux build can be fixed.
any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs.
any suggestions for better text to put for this error message so the next person will be less likely to be confused?
any suggestions what to name the command line switches and how to describe them?
any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
any time you transfer money out of it, then you must no longer use any previous copies.
any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain.
any transactions you send would cost an extra 0.01.  there's no reason to use more than 0.01. it's just there in case we need it.
anyone can check the signatures to verify the chain of ownership.
anyone else able to reproduce this problem?
anyone else who hits this problem, move the database\log.000000000* files somewhere else.
anyone have pentium 3 or older where this would be a problem?
anyone know how many connections typical p2p software like bittorrent can get up to?
anyone trying to steal a micropayment would probably not be a paying customer anyway, and if they want to steal intellectual property they can use the file sharing networks.
anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them.
anyone who wants to keep doing business would be motivated.
anyone with some extra bandwidth quota could throw it on their webserver and run it.
anyone's chance of finding a solution at any time is proportional to their cpu power.
anything gpl please clearly mark it as such.
anything sent to these ips should be considered a donation.
anything that grants access to something, like something that takes a while to download, access to a website, web hosting, a subscription or service, can be cancelled a few minutes later if the transaction is rejected.
anything that's used more than once probably becomes a function in util.cpp that has the #ifdef in it.
anyway, do we really want sourceforge tracking everyone?
anywhere from 60000-74000 is good.
apparently, db_private doesn't do what you would hope it would do, which is prevent other processes from being able to open the database.
applications if you could effortlessly pay a few cents to a enough people think the same way, that becomes a self fulfilling prophecy.
approx, average, but still they're going to think that way.
apps that do dns..." warnings are nothing to worry about.
are pm notifications still disabled?
are there additional locking or coordination files then?
are you back to talking about the existing bitcoin system here?
are you going to manually review and enter orders, at least to begin with?
are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?
are you just trying to run the program or do you really need to compile it?
are you sure you didn't run "bitcoind"?
are you sure you weren't running a single processor hog?
are you using -addnode?
are you using the "-connect" switch?
are you using wxwidgets 2.9.0?
around 400 khash/s per processor is typical.
as a user i'm a little annoyed when it takes time to verify the identity of some no-name site i casually came across.
as an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.
as an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it.
as bitcoin grows, the number should grow too.
as computers get more powerful, the difficulty increases to compensate.
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.
as i recall, the code was nearly ready for a 0.3 release.
as later blocks are chained after it, the work to change the block would include redoing all the blocks after it the proof-of-work also solves the problem of determining representation in majority decision making.
as long as a majority of cpu power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
as long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.
as long as the interface is designed for things like showing the user the last n transactions history, it's fine, now that we have the accounts feature making it easier to do payment detection the right way.
as long as they reach many nodes, they will get into a block before long.
as more people catch on, they'll set up more and more phony addresses to harvest it.
as much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.
as of this moment it's at 375 blocks.
as people cash in and actually get paid, word would spread exponentially.
as such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.
as the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.
as the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them.
as the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.
as trust systems go, ripple is unique in spreading trust around rather than concentrating it.
as you've said, it's futile and can be trivially defeated with sock puppets.
assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.
at 1kb per transaction, that would be 15gb of bandwidth for each block generating node per day, or about two dvd movies worth.
at a minimum you either have to pay the cost in electricity or pay someone the cost of production to make them for you.
at each point, the next field in the data structure is expected.
at equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a lan.
at first glance, bitcoinshop.com looks better.
at first it would mostly be seen as a way to get free money for your computer's idle time.
at least now i know what's wrong now.
at least on debian/ubuntu, all but wxwidgets are available as packages.
at least pentium 3's could run it without generating.
at least some method names are going to change.
at least, that's how it should work.
at most, they are advice that something has been received, but counting them as balance or spending them is premature.
at some point, it gets too expensive for them to buy any more.
at surface level, not looking into any details yet, the current front runners are: its a security question is it possible to open a socket that can only be accessed locally?
at that point, be patient.
at that size, you just need to see that it's a coin.
at that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.
at that time, 1m is a good number to keep the network going and,„Ç‚†therefore, the experiment.
at the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.
at the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you're redirecting from another port number.
at the moment, you can kind of use -connect.
at the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.
at the very least a warning dialog explaining that it'll connect to the ip and send the information cleartext, giving the chance to cancel.
auto-run might give us 300% more nodes while linux might give us 3% more.
auto-running as a minimized tray icon by default was the key to success for the early file sharing networks.
autoconf is a necessity for large projects with a quagmire makefile, but i think we're small enough that it's more optimal without it.
automatic update, or at least notification of new versions, is definitely on the list.
average transaction bytes per block was 428 bytes, or 214 bytes per transaction.
avoiding cpu power fragmentation is no longer a reason.
bandwidthwise, it's more efficient than if you downloaded an archive.
banks let anyone who has your name and account number drain your account, and you're not going to get it back from nigeria.
banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve.
basically like an ebay site with user reviews to try to establish which sellers can be trusted.
be aware, it takes a little time to increase the pool size, so don't go crazy with it.
be careful where you search domain names, many will front-run you.
be sure to upgrade to v0.1.3 if you haven't already.
because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.
because it saw a longer chain existed that it was unable to accept.
because of all the dependencies that different systems don't have.
because of that, i wanted to design it to support every possible transaction type i could think of.
because the first one was slow, it ended up requesting the blocks from everybody else, which only bogged everything down.
before i implemented that, it was annoying having a dead hung unresponsive window hanging around.
before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>).
before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private.
before svn 184, compiling transactions into a block used an n^2 algorithm.
before terminating, it tries closing the socket that's hung.
before the original release i did a test dropping 1 out of 4 random messages under heavy load until i could run it overnight without any nodes getting stuck.
being open source means anyone can independently review the code.
besides the irc part, how did your test of proxy go?
best to only send to bitcoin addresses then.
better than the old one?
big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function.
big-endian is on its way out anyway.
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.
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.
bitcoin 0.2 is here!
bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit.
bitcoin addresses are the only place where 160-bit hash is used.
bitcoin and all timestamp servers share the basic functionality of periodically collecting things into blocks and hashing them into a chain.
bitcoin and bitdns can be used separately.
bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them.
bitcoin can already scale much larger than that with existing hardware for a fraction of the cost.
bitcoin can get the list of ips from any bitcoin node.
bitcoin clients currently only create and recognize transactions that match two possible templates.
bitcoin does a careful shutdown in case it might be in the middle of an important transaction, but actually it's completely safe to kill it.
bitcoin doesn't use dns at all in proxy mode.
bitcoin generation should end up where it's cheapest.
bitcoin got 0% of cpu according to the task manager.
bitcoin has its own distributed address directory using the "addr" message.
bitcoin has unique properties that would be complementary.
bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.
bitcoin is a new design for a fully peer-to-peer electronic cash system.
bitcoin is a small beta community in its infancy.
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.
bitcoin is at its most vulnerable in the beginning when the total network cpu power is small.
bitcoin is practical for smaller transactions than are practical with existing payment methods.
bitcoin is still very new and has not been independently analysed.
bitcoin is the reverse, in that it's easy to get bitcoins just by generating them.
bitcoin isn't currently practical for very small micropayments.
bitcoin might be trying to overcome it by reconnecting.
bitcoin necessarily takes a fair bit of memory; about 75mb on windows.
bitcoin only downloads the data in blk0001.dat, which is currently 55mb, and builds blkindex.dat itself, which is 47mb.
bitcoin opens that up.
bitcoin then pops up the send bitcoins dialog with the destination bitcoin address and amount already filled in.
bitcoin uses ec-dsa, which can only do digital signing, not encryption.
bitcoin uses ec-dsa, which was essential for making the block chain compact enough to be practical with today's technology because its signatures are an order of magnitude smaller than rsa.
bitcoin v0.1 alpha release announcing the first release of bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending.
bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is gavin andresen, barack obama, or satoshi nakamoto.
bitcoin was meant to be both technically and socially robust.
bitcoin will not relentlessly keep re-adding it if you delete it manually.
bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to "porn guys", or afraid of recurring billing.
bitcoin would be running on the web server, and server side script could call it to do transactions.
bitcoin's built-in addr system is the main solution.
bitcoin's irc client implementation is already thoroughly tested.
bitcoin's solution is to use a peer-to-peer network to check for double-spending.
bitcoin's total circulation is limited to 21 million coins.
bitcoin, on the other hand, is easy to get in small amounts anonymously.
bitcoin-linux-0.1.6-test1.tar.bz2 attached the linux build is ready for testing on the network.
bitcoin.org has been down for several hours.
bitcoin.sourceforge.net looks fine now.
bitcoind now compiles without wxwidgets or wxbase in svn rev 112. main(int argc, char* argv[]) is added to init.cpp.
bitcoind runs as a daemon and can either be controlled by command line or json-rpc.
bitcoinexchange.com might be better than bitcoinx.com.
bitdns users may not want to download everything the next several unrelated networks decide to pile in either.
bitdns users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
blinding, in a nutshell, is x = (x * large_random_int) mod m. when paying to a bitcoin address, you would generate a new blinded key for each use.
block broadcasts are also tolerant of dropped messages.
block generation in the segment would take several hours per block.
block generation is again running ahead of pace.
blocks are appended to blk0001.dat files on disk.
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.
blocks contain a history of the bitcoin addresses that a coin has been transferred to.
bluesky offered to do translation on the forum.
boost is good, portable stuff, we should not shy away from it.
both 0.2 and 0.3 have a backup way of getting connected without irc, it's just slower to get connected.
both copies will get screwed up.
both have smf bridge modules available.
bottom line is i'd rather call an existing file copy function than make and test my own.
bouncing between 0 and 2 connections could be if it's connecting to itself.
brass is shiny and similar in colour.
btw, are you able to use my builds of bitcoind on your host, or do you have to build it yourself?
btw, i did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0. i really appreciate the effort, but there are a lot of problems.
btw, i have a lot of uncommitted changes right now because it includes some crucial protocol transitions that can't be unleashed on the network until i've tested the heck out of it.
btw, i haven't tested it, but i hope having rpcpassword=  in the conf file is valid.
btw, i tried boost 1.34 but it didn't have the boost.interprocess stuff.
btw, i tried to buy bitcoin.com before i started but there was no chance, it's owned by a professional domain speculator.
btw, if we want to supplement by deploying separate directory server software, may i suggest irc?
btw, in my tests, vc8 produced an exe that would only run on systems that had vc8 installed on them.
btw, in things like the feature list credits, do you want me to refer to you as sirius-m or martti malmi?
btw, it's looking like i may be able to get us some money soon to cover web host costs, back your exchange service, etc, in the form of cash in the mail.
btw, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).
btw, zetaboards insists on displaying "member #", so you better sign up soon and grab a good account number.
build-unix.txt and makefile.unix added debug.log moved to the data directory "%appdata%/bitcoin/debug.log" 7 inbound and 2 outbound sounds about as expected.
build-unix.txt is updated and two makefiles on svn: unfortunately there's still no debian package for either version of wxwidgets we use.
building blkindex.dat is what causes all the disk activity.
building the tx index is much more random access per block.
builds: it would have been nice to get this attention in any other context.
businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
but 1.0 sounds like the first release.
but as long as the link is already doing the typing for you, i don't see much benefit in using a domain address instead of bitcoin address.
but don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally.
but ec-dsa can't encrypt messages like rsa, it can only be used to verify signatures.
but for analytical attack, it seems like you must analytical attack both ripemd-160 and sha-256.
but for now, while it's still small, it's nice to keep it small so new users can get going faster.
but if someone has 50%+ of the cpu power and malicious intent, they can prove what it already says in the design document.
but if that's the only way to make sure we don't send e-mails to un-verified addresses, then we could do that.
but if the network didn't know all the values and lineage of the transactions, it couldn't do 2), i don't think.
but if the problem is validating loads of transactions, then pow could be checked faster.
but if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, i think people would still take up something.
but it doesn't claim to be practical for arbitrarily small micropayments.
but it would be really nice if this was working on most cpus.
but now that we've enabled it, our verification e-mails are blocked.
but now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.
but still, decades are needed.
by convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.
by doing a fork in this way, these developers are violating the "original vision" they claim to honour.
by making our __m128i variables aligned and changing these inlines to defines, i was able to get it to work on 4.4.1 with -o0 only: but that's with -o0.
by making some adjustments to the database settings, i was able to make the initial block download about 5 times faster.
by moore's law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10.  even if bitcoin grows at crazy adoption rates, i think computer speeds will stay ahead of the number of transactions.
by standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for utf-8 internationalization.
by the time the book "how i got rich exploiting spammers and you can too" is coming out, there'll be too many fake addresses and the spammers will have to give up.
caching would be effective, since most dependencies are recent.
caddress is about the only object with significant reserved space in it.
can anyone confirm if json-rpc over http is supposed to use status 500 if the reply is an error reply?
can nodes on the network tell from which and or to which bitcoin address coins are being sent?
can nodes tell which bitcoin addresses belong to which ip addresses?
can public nodes see the values of transactions?
can someone find the link for that?
can someone put someone else's e-mail address without verifying it, then have stuff sent there?
can someone test each language on ubuntu and see if there's a problem with just one of them or maybe all three?
can someone write some instructions on the wiki explaining how to turn off or add an exclusion to live protection or whatever its full proper name is.
can they see which previous transaction the value came from?
can we live with that as our logo?
can you build?
can you give me any examples of other stuff that does it that way?
can you make sure there's nothing else you can think of that might be acting as an open e-mail gateway or way for spammers to use our system for putting out spam?
can you make the setup uninstall the startup folder icon?
can you provide more details about what removing db_private does?
can you receive it and act as the project's treasurer?
can't wait to overtake it.
cancel and delete unsourced broadcasts cancel subscriptions disconnect nodes disconnect duplicate connections in case two nodes connect to each other at once, the lower ip disconnects its outbound connection disconnect unused nodes remove from vnodes hold in disconnected pool until all refs are released delete disconnected nodes wait until threads are done using it find which sockets have data to receive timeout.tv_usec = 50000; frequency to poll pnode->vsend debug accept new connections service each socket receive typical socket buffer is 8k-64k socket closed gracefully socket error send number of connections may still need to be increased before release initiate network connections make a list of unique class c's taking advantage of mapaddresses being in sorted order, with ips of the same class c grouped together.
case 3 comes into play for small amounts.
cashing out is very easy.
casual users seems content to assume that the system works as stated (which it does), and getting into the design details just opens a can of worms that can't be answered without a deep understanding of the system.
certainly before another sending method is it would be nice to only need the bitcoin address and have the ip worked out behind the scenes.
certainly too trivial to clutter the user's attention with.
changed the version number to 1.3 and removed "beta".
changes: - added some dos limits, though it's still far from dos resistant.
changes: - fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again - isstandard() check to only include known transaction types in blocks - jgarzik's optimisation to speed up the initial block download a little the main addition in this release is the accounts-based json-rpc commands that gavin's been working on (more details at btw, password hashes = passwords.
changes: - new getwork, thanks m0mchil - added transaction fee setting in ui options menu - free transaction limits - sendtoaddress returns transaction id instead of "sent" - getaccountaddress <account> the ui transaction fee setting was easy since it was still there from 0.1.5 and all i had to do was re-enable it.
changes: - some blk*.dat checking on load - built the -4way code with -march=amdfam10, which makes it a little faster - warning if your clock is too far off - warnings/errors/alerts can also be seen in the getinfo command - alert system the alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.
cheaper will usually have some offsetting drawback in quality.
check if the "%appdata%" directory exists, and "%appdata%\bitcoin" does it work then?
check start string check the command string for errors must be all zeros after the first zero message size disk only socket flood inventory based relay broadcast and subscription fclient = false; set by version message push a version message we're using mapaskfor as a priority queue, the key is the earliest time the request can be sent patch in the size printf("%02x ", vsend[i] & 0xff); put on lists to offer to the other nodes save original serialized message so newer versions are preserved expire old relay messages global state mapnexttx is only used anymore to track disk tx outpoints used by memory txes mapkeys mapwallet inserts only if not already there, returns tx inserted or tx found debug print merge write to disk notify ui refresh ui reaccept any txes of ours that aren't already in a block rebroadcast any of our txes that aren't in a block yet ctransaction load the block this tx is in update the tx's hashblock locate the transaction fill in merkle branch is the tx in a block that's in the main chain relinquish previous transactions' posnext pointers get prev tx from disk version -1 tells unserialize to set version so we write back same version relinquish posnext pointer write back put a blocked-off copy of this transaction in the test pool remove transaction from index resurect single transaction objects take over previous transactions' posnext pointers get prev tx from single transactions in memory get prev tx from disk version -1 tells unserialize to set version so we write back same version if tx will only be connected in a reorg, then these outpoints will be checked at that time verify signature check for conflicts flag outpoints as used write back tally transaction fees add transaction to test pool add transaction to disk index delete redundant single transaction objects coinbase is only valid in a block, not as a loose transaction check for conflicts with in-memory transactions and allow replacing with a newer version of the same transaction check against previous transactions store transaction in memory if updated, erase old tx from wallet find the block it claims to be in get merkle root make sure the merkle branch connects to this block cblock and cblockindex cache go back 30 days load first and last block limit one change per timespan work back to the first block in the orphan chain issue here: it doesn't know the version watch for transactions paying to me find the fork list of what to disconnect list of what to connect pretest the reorg invalid block, delete the rest of this branch disconnect shorter branch connect longer branch add to block index new best adding to current best branch new best branch new best link relay wallet transactions that haven't gotten in yet scan ahead to the next pchmessagestart, which should normally be immediately at the file pointer.
check the e-mail logs and see if there's been a lot of traffic and what it's from.
circulation will be 21,000,000 coins.
client commands are without any switches, as such: applications would normally use json-rpc directly, not command line.
cmyapp and the startup folder stuff are moved to ui.cpp.
codewise, there's not much that's easy right now.
coin creation will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation.
coincidentally, i recently coded a replacement for the function in question which should fix it.
coins generate at the same speed with any number of connections >= 1. more connections just add redundancy.
come to think of it, there isn't even an exception print at the end of debug.log.
command line control is one of the next things on the list.
comment, confirmations, credit, debit.
commerce on the internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.
compared to an old cpu, a newer cpu doesn't show as much of a speedup at hashing as it does on general benchmarks.
competition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.
completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes.
computers have to get about 2^200 times faster before that starts to be a problem.
configure tor to generate a .onion address, restart tor, configure it with the generated address.
congrats on your first transaction!
connections are still made, but no data is passed.
consensus is joomla has a better selection of themes and is easier to learn, though drupal may be more intuitive for programmers and customization.
considered autoconf.
consumers seem comfortable with that.
contorting our database usage will not be the right approach.
convert the hash of a file to a bitcoin address and send 0.01 to it: i'm not talking about the normal risk for a given minconf level, i'm talking about additional pitfalls from listtransactions when used this way.
copy the body of the function above it, like this: the modified version of serialize.h is attached.
could a few people please run this special build?
could be anything really, "en" or your language 2-letter code) - put your .po file there - open it with poedit - in poedit, catalog->update from sources the key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.
could be free, or maybe require consuming another domain object to renew.
could represent the right to own a domain for a year.
could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?
could you grep cpuid your debug.log and tell me what it says?
could you send me the debug.log from the 0.1.3 crash?
could you send me the python code you used?
could you send me your debug.log?
couldn't hurt.
cpu family 6 model 26 stepping 4 is an intel core i7.
creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people.
credit card companies hate that.
credit card is only one way.
critical_block isn't perfect.
cross-platform to windows is a plus.
crypto may offer a way to do "key blinding".
curious, why is it incredibly hard to provide wxwidgets 2.9.0?
currently it's only enabled in the linux build, so if you get it to work you could make it available to windows users.
currently, businesses accept a certain chargeoff rate.
currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
currently, paying a fee is controlled manually with the -paytxfee switch.
currently, receivers only accept two templates: direct payment and bitcoin address.
currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.
custom3 online now is a more standard layout similar to a lot of commercial software homepages.
damn that glibc_2.11.
data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.
davidonpda, were you also running laszlo's build previously?
db_private is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.
db_private is the worst of both worlds.
debug.log is all i need then.
debug.log may grow rapidly so be ready to kill it.
debug.log might have clues.
debug.log should tell something if that was the case.
definitely needed.
definitely time to lower it.
definitely.
denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
details, download and screenshots are at www.bitcoin.orgi think it achieves nearly all the goals you set out to solve in your b-money paper.
did i do something unintended?
did it need to be rebooted, or was it a dos or something?
did it print anything to the console?
did they say why they were baffled?
did you compile it or is this a release build, and what version?
did you get any "not accepted" blocks?
did you get back to davidonpda about his doing a mirror backup?
did you run it on a drive where files aren't sorted alphabetically, like a fat drive or usb flash drive?
did you try -4way?
difficulty just increased by 4 times, so now your cost is us$0.02/btc.
digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.
disk only cdisktxpos posnext;  so far this is only used as a flag, nothing uses the location the basic transaction that is broadcasted on the network and contained in blocks.
disk space is about 1k per key.
dns entry.
do all amds that support 64-bit have the better sse2 hardware also?
do blocks contain a history of where bitcoins have been transfered to and from?
do i need to re-integrate the custom captcha stuff or do we have another solution now?
do most p2p clients typically have upnp enabled by default?
do not accept bitcoin transactions as payment until you upgrade to version 0.3.6!
do you do any backups, or the vps do any for you automatically?
do you get that error with 0.2 also?
do you have a weird video card, display setup or running it on a tablet or mobile or something?
do you have any ideas on this?
do you have dual-proc?
do you have electronic transfer or paper cheque in your country?
do you have version 4.7.25 of berkeley db?
do you know what caused that outage?
do you mind if i cc the rest of this to bitcoin-list or cryptography?
do you remember the apt-get command to install gtk, and can you install it without having a gui installed?
do you think anonymous people are looking to be completely stealth, as in never connect once without tor so nobody knows they use bitcoin, or just want to switch to tor before doing any transactions?
do you think i should make the directories: here's rc1 for linux for testing: (link removed, see below) it contains both 32-bit and 64-bit binaries.
do you think it's safe, or do you feel insecure about doing that?
do you think people won't be able to understand the benefit?
do you think psiphon is the best one currently?
do you want to pay the fee?"
does drupal have any special multi-language support, or do you just create copies of pages by hand?
does http basic authentication get us any additional benefits?
does it actually work after just that one change?
does it happen every time you run it, or just happened once at some random time?
does it hide any information from the public network?
does it hide the bitcoin addresses?
does it only work with the msvc and intel compilers?
does it slow down half way through or is about the same speed the whole way?
does it still do it if you didn't do getinfo?
does it substantially reduce performance by making it have to write out every change immediately or do other coordination?
does removing db_private make it safe for other processes to open the database simultaneously?
does the program have write access to the file?
doesn't work right now.
doing your own verifying and indexing is the only way to be sure your index data is secure.
don't even talk about the idea of returning money to customer's credit cards.
don't let it connect to the network before we've tested it thoroughly off-net.
don't rush ahead and get yourself rejected from all the payment options before you've had time to see if there's a better approach.
don't sticky the topic, nobody looks up there.
don't update the block chain download.
don't use listtransactions!
don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser.
don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0.  a setup program completely installs everything, it's not hard like it used to be.
don't use this patch, it'll make you incompatible with the network, to your own detriment.
don't you have an ubuntu laptop you can test and compile on so you don't have to toy with the vps?
donation tokens, currency for a game or micropayments for adult sites.
donations should be able to keep it filled.
done in svn rev 137 i'd like to reduce the number of blocks displayed in the status bar by 1.   when you first load the program, it'll display 0 blocks instead of 1: "0 connections    0 blocks     0 transactions" it's always been "nbestheight + 1" because it's counting the genesis block.
doubleclick on the generated transaction.
doubleclick on the transaction.
download (windows, and now linux version available) new features satoshi nakamoto - multi-processor support for coin generation - proxy support for use with tor - fixed some slowdowns in the initial block download we also have a new forum at many thanks to martti (sirius-m) for all his development work, and to new liberty standard for his help with testing the linux version.
download from sourceforge: it is no longer necessary to delete blk*.dat.
download link: bitcoin-0.1.3.rar - unpack the files into a directory - run bitcoin.exe - it automatically connects to other nodes if you can keep a node running that accepts incoming connections, you'll really be helping the network a lot.
download links are on the homepage now.
download links available now on bitcoin.org.
download links: just leave the old one alone!
download: as a thought experiment, imagine there was a base metal as scarce as gold but with the following properties: - boring grey in colour - not a good conductor of electricity - not particularly strong, but not ductile or easily malleable either - not useful for any practical or ornamental purpose and one special, magical property: - can be transported over a communications channel if it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.
download: http://www.bitcoin.org - unpack the files into a directory - run bitcoin.exe - it automatically connects to other nodes if you can keep a node running that accepts incoming connections, you'll really be helping the network a lot.
downloads: it's not the downloading that takes the time, it's verifying and indexing it.
drupal puts the <spanthat's fine for testing.
drupal's .htaccess file which uses mod_rewrite to allow clean urls without the ?
drupal's forum is less bad than the wikis, but still a long way from something i would want to use.
drupal's urls are search engine friendly, joomla not.
during the block download, it only flushes the database to disk every 500 blocks.
during those 2 minutes, the merchant's nodes can be watching for a double-spent transaction.
e-bay manages to work fine even though shipped goods can't be recovered if payment falls through.
e.g.
e.g; being able to route bitcoin through tor.
each computer's chance of finding a hash collision is linearly proportional to it's cpu power.
each has a kernel of usefulness that helped bootstrap the process, but the monetary value ends up being much more than the functional value alone.
each node sends its neighbours an inventory list of hashes of the new blocks and transactions it has.
each node's influence on the network is proportional to its cpu power.
each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.
each time you try, your chances of success are the same.
each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
ecdsa can't encrypt messages, only sign signatures.
ecdsa doesn't take much time to generate a keypair.
edit: sourceforge is updated now.
edit: that is, assuming there actually are any libraries that don't support content-length.
eff is really important.
either disallow all notification, or make sure e-mail addresses are verified.
either get the src directory from a release, or download it with svn.
either online delivery by sending the card number by e-mail, or delivery of the unopened physical card in the mails.
either party always has the option to release it to the other.
either that or you could have them send to your ip address, but then you have to rely on them to put the order number in the comment.
either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 btc.
either you tell it crypto proof of something, or it ignores you.
email me a simple accounting when you take out money for expenses, like: $100-200 is chump change if they're a serious company, it would only make us sound small.
enough time has passed for a safe transition, and the site looks good.
escape the arbitrary inflation risk of centrally managed currencies!
escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.
especially if you're on a cable modem, the uplink can be much lower bandwidth so it would take some time to upload the block request list.
even for something as non-ui as wxstandardpaths i got nailed.
even if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend.
even if hardly anyone else is posting, i have seen project forums where most of the posts are the author announcing what's going on with the latest changes.
even if i wasn't using it secondarily as a way to allocate the initial distribution of currency, pow is fundamental to coordinating the network and preventing double-spending.
even if ours is probably better, it's an unknown, so people can imagine anything.
even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker.
even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.
even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.
even if you find a block in 3 hours, keep it running continuously for a few days at least.
even if you had automation, you'd probably want to review orders manually before processing them anyway.
even if you haven't, you can bootstrap from seed nodes.
even network solutions, although they've said they won't if you use their whois page not the homepage.
even so, i'm uncomfortable with explicitly saying "consider it an investment".
even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.
even those who don't use the conversion still benefit from knowing that they could.
even though it doesn't say anonymous until the bottom, i think anonymous seekers would already suspect it based on all the other attributes like no central authority to take your id info and the way bitcoin addresses look.
even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level.
even though not much rank has accumulated yet, the original start date becomes extremely important if the site gets popular later.
eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.
eventually there'll be some interest in brute force scanning bitcoin addresses to find one with the first few characters customized to your name, kind of like getting a phone number that spells out something.
eventually they'll provide a 2.9 package.
every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node.
every assumption in the existing code is that you're not trying to write double-spends.
every bitcoin node displays the same number and it goes up about every 10 minutes whenever someone generates a block.
every coin is entitled to turn over so often.
every conventional payment method has refutability as their way to cope with their lack of passwords and crypto.
every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code.
every node and each processor has a different public key in its block, so they're guaranteed to be scanning different territory.
every node could see that and reject it before relaying it.
every other systray icon on my computer is in the startup folder, and it makes it easy for users to manage all their autoruns in one place.
every p2p file sharing program has instructions how to do it.
every transaction is one of these.
everybody needs to connect to the same irc server and channel so they can find each other.
everyone else has said 4way was faster on i5.
everyone faces the same rate of unaccepted, it's just a part of the process.
everyone should upgrade to get this change.
everyone should upgrade to this version.
everyone would have to make sure no user can create account name "*".
everyone would have to upgrade by that time.
everyone would have to upgrade their software by that block number.
everything else is sha-256.
everything else looks normal.
everything is always harder to build on windows than linux.
everything that uses captcha has to have that mycode=4 thing added.
excellent analysis, xc.
excellent choice of a first project, nice work.
except that wouldn't work for boost 1.40+ (on ubuntu 10.04), where you need to get libboost-all-dev.
exit bitcoin and start it again.
exit codes can only be 0-255 on unix, so it's abs(code)%256.
exponentially larger steps back find the first block the caller has in the main chain find the first block the caller has in the main chain global state variables new address services have been added if the dialog might get closed before the reply comes back, call this in the destructor so it doesn't get called after it's deleted.
extranonce is not part of the block header, it is part of the first transaction.
extranonce never needs to be very big.
eyeballing it i don't see anything obvious.
faster machines just get a larger share than slower machines.
faster than twice a second?
fat32 filesize max 4gb, fseek and ftell max 2gb, so we must stay under 2gb load from disk debug genesis block: gethash()      = 0x000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646 hashprevblock  = 0x0000000000000000000000000000000000000000000000000000000000000000 hashmerkleroot = 0x769a5e93fac273fd825da42d39ead975b5d712b2d50953f35a4fdebdec8083e3 txnew.vin[0].scriptsig      = 247422313 txnew.vout[0].nvalue        = 10000 ...            txnew.vout[0].scriptpubkey  = op_codeseparator 0x31d18a083f381b4bde37b649aacf8cd0afd88c53a3587ecd... ntime          = 1221069728 nbits          = 20 nnonce         = 141755 cblock(hashprevblock=000000, hashmerkleroot=769a5e, ntime=1221069728, nbits=20, nnonce=141755, vtx=1) ctransaction(vin.size=1, vout.size=1, nlocktime=0) ctxin(coutpoint(000000, -1), coinbase 04695dbf0e) ctxout(nvalue=10000, nsequence=4294967295, scriptpubkey=51b0, posnext=null) vmerkletree: 769a5e genesis block debug print start new block file read index header read block header skip transactions break; is this all we want to do if there's a file error like this?
favicon is a nice touch.
fears about securely buying domains with bitcoins are a red herring.
features: - json-rpc errors return a more standard error object.
finally an easy one.
first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins etc... when that runs out, the system can support transaction fees if needed.
first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins when that runs out, the system can support transaction fees if needed.
first you need normal, basic p2p currency working.
fix will be in test8.
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.
fixed in svn rev 130. true, there would probably be someone with a dial-up modem or satellite dish internet.
flatdata was a workaround to serialize a fixed field length array.
for "normal members" i disabled "request notification on replies" and "request notification on new topics".
for a car salesman, when will the next customer walk in the door?
for a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.
for almost any type of goods, that's not going to be worth it for the scammer.
for blocks or transactions you create if they don't get out to any other nodes.
for brute force, ripemd-160(sha-256(x)) is no stronger than ripemd-160 alone.
for consistency, i used __bsd__.
for details on how it works, see the design paper at the result is a distributed system with no single point of failure.
for example i didn't anticipate pooled mining and its effects on the security of the network.
for example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts.
for example, if 0.001 is worth 1 euro, then it might be easier to change where the decimal point is displayed, so if you had 1 bitcoin it's now displayed as 1000, and 0.001 is displayed as 1. ripple is interesting in that it's the only other system that does something with trust besides concentrate it into a central server.
for example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment.
for future reference, drupal's is named "smfforum integration".
for future reference, here's my public key.
for future reference, the files in sources with customisations are: let me know whenever you do an upgrade so i can make sure all my changes survived.
for good measure, i changed it to make the shortcut settings look identical to one i manually created.
for greater privacy, it's best to use bitcoin addresses only once.
for instance, i haven't researched the best way to do the "start bitcoin on system startup" feature on linux.
for instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double: also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.
for instance, if port 8334 forwards to a computer's port 8333, then senders could send to "x.x.x.x:8334" if your nat can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but i'll look into it.
for instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow?
for instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49.  previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.
for json parsing i'm using json spirit, which makes full use of stl and has been really nice to use.
for me it seems like https sites fail to load a lot more often.
for micropayments, you can safely accept the payment immediately.
for most of last year, we were hovering below the minimum.
for now i made the default pool size 100.  it can be configured with -keypool=.
for now you still have to do it manually.
for now, can some people running 0.3.10 with static ip who can receive incoming connections post their ip?
for now, everyone just runs a full network node.
for now, if things work out like the real world where the vast majority of transactions are with merchants, they'll pretty much always make sure to set up to receive by ip.
for now, it's pretty obvious that if you send to an ip, you didn't that's correct.
for now, recommended steps: 1) shut down.
for now, you can just multiply the total blocks by 50.  the bitcoin network has been running for almost a year now.
for now, you could also subscribe to the bitcoin-list mailing list.
for one thing, not being so blunt about "money burning" for the purposes of game theory discussion.
for our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.
for our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.
for privacy reasons, the software already uses a different key for every transaction, so every piece of money in your wallet is already on a different key.
for redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them.
for security, i'd almost rather have a different login than be constantly checking the forum with the same login that could pwn the website.
for services that could almost be free but not quite.
for smaller projects, i think the fear of a closed-source takeover is overdone.
for some things newness is a virtue but for this type of software, maturity and stability are important.
for that level of anonymity you need to connect through tor, which will be possible with version 0.2, which is only a few weeks away.
for the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers.
for the moment, you can grep the debug.log file for "generated" and "hashmeter" for some feedback.
for those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log.
for today, try adding these parameters: -addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14 right, it will get reincorporated into the fixed chain.
forgot to add the good part about micropayments.
forgot to say, i suspected the detect might not work on 64-bit amd.
fortunately, it's standard for open source projects to be .org.
fortunately, so far all the issues raised have been things i previously considered and planned for.
free transactions are nice and we can keep it that way if people don't abuse them.
free transactions would just take longer to get into a block.
freenode is too visible, right in the middle of where all those users and moderators are hanging out.
from a thread on p2presearch which starts with my rant about trust being the root weakness of all conventional financial systems.
from what i've seen on other forums, if the cost of bandwidth becomes an issue, a small google adwords (text links) at the top generates more than the cost of bandwidth even for very low value traffic like gaming.
full size 530x529 image for scaling down to custom sizes: the perspective shadow was too thick on the larger sizes.
funnelling all the ui backend through a tcp connection would make everything twice as hard.
future versions after 0.3.8 will probably require sse2.
future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.
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.
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.
gavin's changes look good.
gavin's point seems stronger.
gavin, could listtransactions have an option to list transactions for all accounts?
gcc 4.3.3 doesn't support -march=amdfamk10.
gdb is easier to use than you'd think.
gdb.exe is the only file.
generated blocks take about 24 hours before they're credited to your balance.
generated coins must wait 120 blocks to mature before they can be spent.
generated domains start out blank and the miner sells it to someone who changes it to what they want.
generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.
generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating.
getallreceived 0 should do what you want.
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.
getreceivedbyaddress would always count only one or the other spend at any given time, never both.
getting antsy to port to linux?
getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.
getting the linux version to run without the gtk installed will be a separate task.
getwork allows these problems to be solved separately, with different programs for different hardware and oses.
getwork does the byte-reversing.
give it a try, or take a look at the screenshots and design paper: download bitcoin v0.1 at http://www.bitcoin.org the root problem with conventional currency is all the trust that's required to make it work.
glad that worked, it's a pain that the dependencies are so big and hard to build.
glad that you've been handling things in my absence.
gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.
gold, for instance, is pretty, non-corrosive and easily malleable, but most of its value is clearly not from that.
good idea about the sourceforge tag, we can use all the graphics we can get.
good idea, i made a change to make sure it won't generate before checkpoint block 74000. the order matters not to the program, but it matters to me maintaining it.
good luck on your c++ project.
good news: he says he made his first sale of bitcoins.
good point.
good question, it's tcp.
good suggestion.
good to know it's ok at the current size, and now they know who we are.
good, so i take it that's a confirmation that it's working on mac as well?
good, that gives them a little sense of ownership and responsibility.
good, then no need to consider d-bus.
google allows a certain number of properties like ip address or content of the site to change without deleting your site history.
got the test working on 32-bit with mingw gcc 4.5.  exactly 50% slower than stock with core 2. if you haven't already, try aligning thash.
gpu miners, please upgrade as soon as possible to shut down the free transaction abuse!
gpu programming is immature and hard to compile, and i didn't want to add additional dependencies to the build.
great, i've been looking forward to working on the linux build.
great... if this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.
gtk doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no gui present, then it's done.
gtk has to be shared linked.
hal finney gave a good high-level overview: abstract.
hal sort of alluded to the possibility that it could be seen as a long-odds investment.
hard to buy because exchangers are very cautious about getting ripped off by reversed payments, so they require more details and holding time.
has an equal chance of being chosen, then an ip is chosen within the class c.  an attacker may be able to allocate many ips, but they would normally be concentrated in blocks of class c's.
has wxwidgets 2.9 finally started to become available as a debian package?
have a way for fans to contact them, they could set up bitcoin and on the transaction to see the full message.
have you copied or moved your wallet.dat in any way?
have you decided on the cms to use?
have you ever had a db exception?
haven't had time to update the svn yet.
haven't looked into it.
having a lot of forum talk gives a project more presence on the net, more search hits, makes it look big, draws new users in, helps solve support questions, hashes out what features are most of wanted.
having more helps keep down the "(not accepted)" issue for now until i reduce the chances of that happening in v0.1.6.
having several connections increases the certainty that you're well connected to the network.
having two incoming ports to the same person doesn't help redundancy.
he can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
he can't fail to pay due to lack of funds.
he can't get the escrow money back.
he carried this torch years ago with his reusable proof of work (rpow).
he doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a poisson distribution with expected value: to get the probability the attacker could still catch up now, we multiply the poisson density for each amount of progress he could have made by the probability he could catch up from that point: rearranging to avoid summing the infinite tail of the distribution... converting to c code... running some results, we can see the probability drop off exponentially with z. solving for p less than 0.1%... 12. conclusion we have proposed a system for electronic transactions without relying on trust.
he had errors probably caused by utf-16 wxwidgets 2.8.  should have better luck now with 2.9.0.  wxwidgets 2.9.0 is utf-8 and wouldn't have that problem.
he has ubuntu 64-bit and i have 32-bit, so i'm assuming that's the difference.
he helped me a lot defending the design on the cryptography list, and with initial testing when it was first released.
he just needs to delete blk*.dat and let it redownload.
he ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.
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.
he seemed pretty certain he was going to send it, maybe more.
he tried moving the datadir to a different drive, no help.
he was generating invalid blocks at difficulty 1.0.  he must have a corrupted entry in his blk0001.dat or blkindex.dat file.
header network and disk memory only connectblock depends on vtx being last so it can calculate offset open history file to append write index header write block open history file to read read block check the header the timechain is a tree shaped structure starting with the genesis block at the root, with each block potentially having multiple candidates to be the next block.
heapchk() is just a msvcrt debugging thing that's not being used.
help.
helpful suggestions, thanks.
here are the patch downloads for windows: steps: 1) shut down.
here's a compilation of questions i've answered in forums and e-mail that should help you see what questions are frequently asked and some answers i've used.
here's a link to the original introduction of the paper on the cryptography mailing list.
here's a quick walkthrough using poedit to make a .po and .mo file: - download the bitcoin sourcecode from svn - in the trunk directory, mkdir locale\<lang>\lc_messages - in poedit, file->new catalog->paths tab - click the "new item" dotted rectangle button - put "../../.." and make sure to press enter to add the path - click ok - save the file as "bitcoin.po" in the lc_messages directory you made - it should then scan the sourcecode and find about 170 strings - if it didn't find anything, check catalog->settings->path tab, make sure the "../../.." was added when you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program).
here's a test build if you'd like to help test before 0.3.9 is released.
here's a test build, please test it!
here's a windows build of it: too late for 0.3.13, but i'll try to find time to add it to the next version.
here's a windows build: this version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it.
here's an answer to a similar question about how to recover from a major meltdown.
here's an outline of the kind of escrow transaction that's possible in software.
here's rc1 for windows for testing: (removed, see rc2 below) please only download this if you're going to test and report back whether everything seems fine or not.
here's rc2, that's the only change in it: (see below for download links) this seems like a good idea.
here's some pseudocode of how you would use the account based commands.
here's the 0.1.3 msvc debug build and the gcc debug build w/gdb.exe definitely the disk full.
here's the code that applies: the timestamp is limited to up to 2 hours in the future.
here's the info about pbl again.
here's the planned release announcement text.
here's the preliminary change.
here's what i did in c++ to keep giving the same key (aka bitcoin address) until they use it: // keep giving the same key to the same ip until they use it ...sends the key mapreusekey[pfrom->addr.ip] ...later... if it's not convenient to know when you've received, just clear the cached keys every 20 minutes.
here's what i ended up with: i saw some sporadic inconsistent model numbers for amd cpus, so i'm not sure if this will catch all capable amds.
here's what i was thinking of.
here's what i've prepared: announcing version 0.3 of bitcoin, the p2p cryptocurrency!
here, you don't have that kind of control over ripemd-160's input, because the input is the output of sha-256.
hey zooko!
his point is that transactions paid to a bitcoin address are only as secure as the hash function.
historically, people have taken up scarce commodities as money, if necessary taking up whatever is at hand, such as shells or stones.
hmm, i think the 8 extra registers added by x86-64 must be what's helping.
hopefully gtk can be installed without having a windowing system installed.
hopefully the 1.1.x line is mature and updates are infrequent.
hopefully the easy solution of just growing up and getting past that stage will work.
hopefully theymos was right that the pbl is the source of the problem.
hopefully with priority, your transactions before that should be at worst slow, not stuck.
how about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it?
how about add to the top of cryptopp/config.h: that would disable sse2 for 32-bit builds.
how can you have a config file where you can't comment out a line to disable it?
how did we get on that?
how do you think we should compile the seed list?
how does everyone feel about the b symbol with the two lines through the outside?
how expensive is heating oil?
how fast is it flickering between 0 and 2 connections?
how fast is their internet connection?
how long did it take to get connected with tor the first time, having to use the seed nodes?
how long did you run it?
how long does wikipedia typically leave a question like that open for comment?
how long is the initial block download taking for you?
how long is the initial block download typically taking?
how many blocks did it say it had left to mature when you sent?
how many blocks do you have?
how many connections did you get, and how long did it take?
how much "dealing with" does gtk actually require?
how much memory do you have to work with?
how much of an improvement do you get with hyperthreading?
how often do you think it should be?
however i acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions.
however with the formal release of bitcoin xt 0.11a, this looks unlikely to happen, and so i am forced to share my concerns about this very dangerous fork.
however, i haven't had time yet to add that option to the ui.
however, that would cause insane traffic for most people.
http basic authentication should be considered.
https://sourceforge.net/account/login.php hal isn't currently actively involved.
hurray!
hurray, i got it on the first go.
hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.
i added a subset of the crypto++ 5.6.0 library to the svn.
i added checking to track whether other nodes received your generated blocks.
i added label related functions to help with managing multiple addresses per user.
i added msg_dontwait to the send and recv calls in case they forgot the socket is non-blocking.
i added some instruction text on the homepage below the screenshots.
i added the cached sha256 state idea to the svn, rev 113.  the speedup is about 70%.
i added the full size to the first post.
i added the sourceforge tracker to bitcoin.sourceforge.net.
i added the switch "-testsafemode" for you.
i added xpm files, which is what they use everywhere else but windows instead of rc files.
i added you (dmp1ce) as a dev to the sourceforge project and gave you access to edit the web space and everything.
i aligned the data fields and it worked.
i also implemented an inactivity timeout as a fallback.
i also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.
i also support a third transaction type for timestamp hash sized arbitrary data.
i also uploaded a few themes into drupal.
i always had reservations about "-?"
i am not claiming that the network is impervious to dos attack.
i anticipate there will never be more than 100k nodes, probably less.
i assume a database op wrapped in a transaction would be logged like any other database op.
i assume anything short of ssl would be pointless against dpi.
i assume it must be in this: you could check that with this: was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key?
i assume that means it e-mail verifies.
i assume the "forum" tab on the homepage can link out to wherever the forum is hosted.
i assume they have the same file permissions as the database files, so the same user access restrictions apply.
i badly wanted to find some way to include a comment with indirect transfers, but there just wasn't a way to do it.
i believe 2.8 and its utf-16 build labelled simply "unicode" has been the source of build problems described in the forum.
i believe a number suitable for mid-term, perhaps, is around 200m, which is sufficient for a transaction rate much higher than the sum of any current center authority banks.
i believe hardware has already recently become strong enough to handle large scale, but if there's any doubt about that, bandwidth speeds, prices, disk space and computing power will be much greater by the time it's needed.
i believe i've fixed the bug related to "select failed: 10038" (error wsaenotsock).
i believe i've worked through all those little details over the last year and a half while coding it, and there were a lot of them.
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.
i believe it's saying it crashed in that.
i believe that„Ç‚†bitcoin is not only an experiment anymore.
i believe the clients would have to keep the entire history back to the original generated coins.
i believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions.
i believe the safer option should be enabled by default.
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.
i built it on ubuntu 10.04.  i hope that wasn't a mistake.
i came to agree with gavin about whitelisting when i realized how quickly new transaction types can be added.
i can add code so new nodes do not preferentially stay connected to the seed nodes, just connect and get the list, so it won't be a burden on them.
i can be criticized for using it, but the syntax would be so much more bloated and error prone without it.
i can compile the crypto++ 5.6.0 asm sha code with mingw but as soon as it runs it crashes.
i can fix this, i just need to think a while about the right way.
i can include it in the stress test i'm currently running on the changes so far.
i can move init and shutdown into init.cpp or start.cpp or something, link only wxbase and not link ui.o and uibase.o.
i can often figure out what went wrong just from that.
i can see both points.
i can still put it back into normal order by making poedit rescan it.
i can subclass initialize, call the original one while suppressing the error message and ignore the return value.
i can usually get a lot just from that.
i can't imagine how 8% more could be squeezed out of it.
i can't imagine how it would fail.
i can't remember if i had a specific reason for db_private, or if i just copied the flags from some example code.
i can't remember where i picked that up, maybe it's wrong.
i can't see how it's happening though, it should be resetting nlasttry which would put it to the back of the queue, but the log doesn't show it.
i can't think of a good solution for the interface, that's the problem.
i can't think of a way to implement that.
i can't understand why you're having so much pain.
i can't use msvc 6.0 for the release because its optimization of the sha-256 routines is too slow.
i changed it back to text for now though so i can keep tweaking the colours.
i changed it to every 30 minutes.
i changed registration-activation".
i changed the makefile to look for things under /usr/local and in their default "make install" locations.
i changed the settings to let it cache the changes in memory and write them out in a batch.
i changed the switch name to -disablesafemode.
i checked all the standard themes and it seems reasonable with all of them.
i checked everything in to svn (thanks for setting that up) - multi-proc generate - flush wallet.dat after every change so the db doesn't leave that stuff in the transaction logs - view menu checkbox to hide all generated coins so you can see just your payment transactions - disabled transaction fee option - made the minimize to tray options similar to firefox's minimizetotray - bunch of other misc changes since the 0.1.5 release i made it not show non-accepted generated coins.
i checked in all my backlog of changes to svn, including the overhaul of ccriticalsection in util.h and openssl's mutex callback in util.cpp to do everything with wxwidgets when not on windows.
i clicked on the wrong e-mail when i was looking for your username.
i committed a fix for 64-bit compile and some fixes to support wxwidgets 2.9.0. there was one compile error in serialize.h with min(sizeof()) that i fixed for 64-bit.
i committed the changes to headers.h.
i compiled and ran on 64-bit ubuntu 9.10 karmic.
i completely put off disk full handling until a later version.
i could only get this working with linux.
i couldn't get wxwidgets 2.8.9 to compile on karmic 64-bit either.
i created a "moderators" group to give my satoshi account as much editing control as possible without the ability to overthrow everything.
i created a satoshi account and it can't even edit the side bar stuff, just the main text of pages.
i credited it to tcatm based on your post in the x64 thread.
i did a rough tally of 4000 blocks from around 74000-78000.  this is excluding the block reward transactions: there were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.
i did some research and it was obscure, but there may be something there.
i didn't change the setup script yet.
i didn't expect to have so much activity so fast.
i didn't make any changes to drupal code.
i didn't make it (+1.23) because parenthesis in accounting means negative.
i didn't realize you were going to document all the intentionally undocumented commands.
i didn't say impermeable, i said good-enough.
i didn't see anything unusual on my end.
i disabled gdm on my ubuntu system so it boots into command line.
i don't anticipate that fees will be needed anytime soon, but if it becomes too burdensome to run a node, it is possible to run a node that only processes transactions that include a transaction fee.
i don't believe a second, compatible implementation of bitcoin will ever be a good idea.
i don't get how it let you send if it was not matured.
i don't get how that's "easy" to track with transactions.
i don't have either to test with.
i don't know a way to implement that.
i don't know anything about any of the bug trackers.
i don't know exactly what it does, but it probably just says something like "yes windows, see i'm in a dll like you insisted."
i don't know how to do svg, but i did the original very large, over 500 pixels across, so it can be scaled down.
i don't know how to fix it.
i don't know if i broke the mac osx build, someone will need to check that.
i don't know if it'll just get the "select failed" error again, or be fine for a while.
i don't know if it's really required to wait for the server to finish looking up hostname before sending nick.
i don't know if these are right or what, but they compile.
i don't know what else to do though.
i don't know what to do for tryentercriticalsection though.
i don't know what you're talking about accepting easier difficulties.
i don't know when i might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
i don't know why i don't see any other software projects using a free forum, but i have to assume there might be a reason we would discover later.
i don't know.
i don't like the 32x32 version.
i don't question that gpl is a good license for operating systems, especially since non-gpl code is allowed to interface with the os.
i don't recommend using anything other than 2.9.0. it looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxbase.
i don't see any visible problems in the code.
i don't think anyone would notice the occasional non-accepteds if we didn't point them out in the ui.
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 don't think i want to invent my own rpc protocol, i want to use an existing standard.
i don't think it should cause any problems for version comparisons.
i don't think makefile.osx on svn has it yet, just the built version.
i don't think the threshold should ever be 0.  we should always allow at least some free transactions.
i don't think user accounts can access any of the admin stuff.
i don't think we should make the site https by default.
i don't think we'll need to get into that much detail though.
i don't think we've heard any i7 results yet.
i don't think you can even set that with -paytxfee, i think you'd have to modify the code to do it.
i don't think you have a particular problem, i think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full.
i don't understand, are you under the impression that the program sets the system clock?
i don't want to do an exchange business myself, but it can be done independently of me.
i don't want to put my money in something that's 1.0.
i don't want to rip and replace streams though, even if it has to read one character at a time.
i doubt there's an mmap(2) on windows.
i doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.
i enabled the wordpress feature and added you as an admin, account sirius-m, e-mail sirius-m@users.sourceforge.net.
i ended up picking something in the middle.
i favour the plan to monitor if the frequency of blocks received drops too slow.
i figure it should install and uninstall an icon in a regular program group, and just uninstall the startup folder one.
i figured linux people wouldn't mind doing that manually anyway.
i find "key value" a little unnatural.
i finished and posted the 32x31 and 48x47 versions in the first message.
i finished everything on my list to do for version 0.3.  the code on svn is about ready to release.
i fixed a few places i found where it was possible for a socket to get an error and not get disconnected.
i fixed a few things and got it to finish compiling but i don't know the system libraries to link to so there's undefined references galore.
i fixed some non-portable stuff i came across: if there's any other unportable stuff you know of i should fix, let me know.
i forgot, when you build debug on msvc, it uses the debug versions of the runtime dlls, which aren't included with windows distributions.
i found it hard to believe but amd reports a different model number in 64-bit mode.
i found some more estimates about how many transactions are online purchases.
i found that sse2 only added a slight 2% speedup, which didn't seem worth the incompatibility.
i found the "to:" in "from: unknown, to: (one of your bitcoin addresses)" still confusing, so i changed it to "from: unknown, received with:".
i found the problem with crypto++ on mingw 4.5.0.  here's the patch for that: mingw gcc 4.5.0: crypto++ doesn't work, x86_sha256_hashblocks() never returns i only got 4-way working with test.cpp but not when called by bitcoinminer mingw gcc 4.4.1: crypto++ works 4-way sigsegv gcc is definitely not aligning __m128i.
i get: hey, you may be onto something!
i got a donation offer for $2000 usd.
i got it linked and ran it and working through runtime issues like getting it switched to load bitmaps from xpm instead of resources.
i got it, i see you checked in the startup folder code before changing it to registry.
i guess for now, this thread serves as the tutorial.
i guess i made the wrong decision, at least for this early version.
i guess i'm leaning towards self parsed mapconfig: still need to know what's the most typical settings file format on linux.
i guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope.
i guess in event driven, bitcoin would be told to run a command line when a certain amount is received to a certain bitcoin address.
i guess it depends what exactly the problem was with it not always working by default.
i guess it doesn't matter that much whether it installs and uninstalls the startup folder icon or just uninstalls it.
i guess it got lost in an upgrade?
i guess it would have to be either in connectsocket or recvuntil.
i guess live protection must have been blocking some other part of the program then?
i guess one answer for the faq should be how to set up your firewall to forward port 8333 so you can receive incoming connections.
i guess recent cpu optimizations must have concentrated on things like i/o and branch prediction.
i guess sourceforge hasn't updated its mirrors yet.
i guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
i guess they need to know about the -min switch to do it right.
i guess to know whether it successfully connected outbound through tor you'd need to search debug.log for "connected".
i guess we could look how wx does it, or maybe the xml-rpc library will already know what to do.
i guess we gotta test windows 7 now.
i guess we should resolve the full path before passing it to the database.
i guess we should try to support the case where there's no content-length parameter.
i guess what we want is an auto-run option that's on by default, if the option is changed then it creates or deletes the startup icon.
i guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.
i had been wondering whether it would be buyers or sellers.
i had been wondering why everyone keeps harping on no-ui, when already you can run it with only a small icon on the tray, which is common for server services on windows.
i had chalked it up to unix snobbery if they couldn't abide a tiny little icon on a desktop they never see.
i had expected those to be a wine problem, but he's getting them on linux just the same.
i had hoped the debate would resolve and that a fork proposal would achieve widespread consensus.
i had imagined an auction, but it would be far simpler and more confidence inspiring to back it at a specific exchange rate.
i had it on bitcoin.org for a minute, but took it off.
i had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50btc, new users could get some coins to play with right away.
i had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent.
i had to do that for makefile.vc also.
i had to go by various random reports i saw.
i hadn't thought about starting out using bitcoind without using bitcoin first.
i hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly.
i hate to blame the compiler, and i've never had a gcc compiler bug before, but this feels like one.
i have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.
i have a feeling most of the time people will get bitcoin addresses off of non-ssl websites and when sending (maybe 1.2.3.4-1kn8iojk...), where the recipient uses and type 2 through dns poisoning.
i have a program i use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before i upload them to svn.
i have been compiling the latest svn on karmic 64-bit with wxwidgets 2.9.0, which compiles fine on 64-bit.
i have been following the recent block size debates through the mailing list.
i have been following the recent development about the block size limit.
i have dual-proc, so i ran two memory hogs.
i have it working fine on gcc 4.3.3 on ubuntu 32-bit.
i have more changes to make, this isn't all of it.
i have more to do before we go live, and we need to give the search engines more time.
i have no idea how long that will take.
i have not addressed the recovery side of this yet.
i have the code already, i'll put it in.
i have the command line and json-rpc daemon version working now.
i have thought about eventually ssling all the connections.
i have time that i can do some testing when you've got something buildable to test.
i have to update all 7 translation files when i change the english text in the program, and it's easier when they're all in the same order.
i haven't got to fixing that yet.
i haven't had any reports of crashes in v0.1.5.
i haven't really tested -maxconnections much, could someone test it?
i haven't seen the shutdown take more than a few seconds.
i haven't tested if it plays nice with other nodes yet so keep it off-net.
i haven't tested my json-rpc server with anything else yet.
i haven't thoroughly gone through all the available themes yet.
i haven't tried compiling 64-bit yet.
i hope i will be able to get it enabled again with rcconf.
i hope it doesn't get deleted.
i hope it's not going to put up this much of a fight for all php users.
i hope someone can test an i5 or amd to check that i built it right.
i hope square brackets is different enough to be clear what is meant.
i hope that's high enough that the transaction fee should rarely ever come up.
i hope there's not a big hurry to wrap the discussion and decide.
i hope they can make the distinction, that this is the first time i know of that we're trying a non-trust based system.
i hope we get at least one .mo file for the software translation in time to put into the 0.3 release.
i imagine it's something about the 32-bit version of berkeley db on 64-bit linux.
i implemented the code to flush wallet.dat whenever it's closed so we'll be able to tell users they only need to backup wallet.dat.
i implemented this change in svn rev 157. the reason i previously made it so high was to allow very large transactions without hitting the transaction fee.
i integrated the hashmeter idea into the svn version.
i isolated the problem.
i just committed a fix to svn for this.
i just don't want to upload it to sourceforge for a quickie share for a day or two, possibly taking it down immediately if there's a bug.
i just e-mailed you my e-mail address.
i just followed the instructions in build-unix.txt.
i just now downloaded my e-mail since the beginning of april.
i just now uploaded rev 134 which is the makefile.unix that enables building with it on linux.
i just posted some sample code showing a suggested way of implementing this.
i just thought of something.
i just uploaded a quick build so testers can check if i built it right.
i just uploaded svn rev 185 which has a minimal priority requirement for free transactions.
i keep a list of all unresolved bugs i've seen on the forum.
i kinda hid the labels after early users found them confusing, but it would be very helpful for this application.
i kinda like not requiring e-mail verification.
i knew i couldn't write that code fast and carefully enough yesterday, so i went with the quick manual option.
i know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.
i know i've been criticized for being reluctant about listtransactions.
i know someone is already doing that to put it on a truecrypt usb drive.
i know the minimize to tray on ubuntu is very clunky, but i didn't know it had a cpu peg problem too.
i know, but not easily without complicating the sourcecode.
i know, most developers don't like their software forked, but i have real technical reasons in this case.
i left a few simple things like wxthread::getcpucount() that i checked the source and it's all numerical, and wxmutex has to be safe or it'd be useless.
i like hal finney's idea for user-friendly timestamping.
i like his approach to estimating the value based on electricity.
i like that in libraries for the external api's, but you can probably tell from the code that i'm not a fan of it for interior functions.
i like the 48 a lot.
i like to keep code compact so you can see more code on the screen at once.
i like to start with a flat namespace until there's enough items to justify subsections.
i like your idea of at least moving the faq into the wiki.
i love the idea of virtual, non-geographic communities experimenting with new economic paradigms.
i made 0.3.0.rc2 available that uses irc.lfnet.org instead of freenode if you want to start switching over: lets try using laszlo's irc.lfnet.org instead of freenode.
i made a couple little corrections for boost 1.37, which i'll put on svn the next time i update it, noted below: what are you needing to use listtransactions for?
i made an admin account you can use to upgrade your own account to admin: btw, the admin pages have a huge blank space at the top, you have to scroll down.
i made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending.
i made some changes to the bitcoin.org homepage.
i made the b slightly lighter and the background slightly darker.
i made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical pc will be able to generate coins in just a few hours.
i make this appeal to wikileaks not to try to use bitcoin.
i may just have it kill itself after a timeout.
i mean a node only needs the pending-tx pool for the best branch it has.
i merged the linux changes into the main trunk on svn.
i mostly have things sorted and should be back to bitcoin shortly.
i must have accidentally typed j instead of z.  it's bz2 format.
i need access to change these files to fix it: here's the planned fix.
i need to get your postal mailing address to have him send to.
i need to give an updated .po file.
i need to hurry up and get 0.2 out the door.
i need to make a way for you to programmatically get new generated bitcoin addresses.
i never would have noticed that if you hadn't pointed it out.
i noticed my custom captcha stuff is gone.
i noticed this in the docs for wxsocketserver::accept(bool wait = true): "if wait is true and there are no pending connections to be accepted, it will wait for the next incoming connection to arrive.
i often come across annoying red links of things that wiki ought to at least have heard of.
i only enabled this change during the initial block download.
i ought to write some sample code showing the proper way to use them, particularly with polling for received transactions.
i plan in v0.1.6 to hide those, since they're just confusing and annoying and there's no reason for users to have to see them.
i plan to implement interfaces for using the software to send and receive transactions from any language, so server side code can easily use it for web based e-commerce sites.
i plan to work on the escrow feature next, which is needed to make actual trades for physical stuff safer and before backing the currency with fiat money can begin.
i posted a sample code fragment on the forum somewhere.
i probably should break out part of addtoblockindex that sets the new best block.
i put it at bitcoin.org/download/linux64-0.2.7.1.tar.gz.
i ran a difficulty 1 test with it and it has generated blocks.
i ran a test where it terminated the thread about 1000 times without trouble, so it should be safe.
i ran some tests.
i ran the windows and 64-bit linux version and checked the about dialog.
i re-ran update from sources and it put it back in the original order so it's fine now.
i read the link someone posted about amd making that change around 2007, but i didn't know what the story was for intel.
i really like that he explains the concept that the cost of electricity is a minimum floor under the price.
i recently updated the svn for building on 64-bit karmic with wxwidgets 2.9.0.  this was after the 0.2.0 release.
i reduced max outbound connections from 15 to 8 in rc4.
i reduced the exe size by running strip.exe on it to take out the debug symbols.
i registered username "satoshi".
i release these images into the public domain (copyright-free).
i removed the word "anonymous", and the sentence about "anonymity means", although you worded it so carefully "...can be kept hidden..." it was a shame to remove it.
i replaced a bunch of stuff at once so i don't know if it was just one thing (probably repaint), but i have to assume even any wx function that uses wxstring is not safe to use outside the ui thread.
i replaced the last of the few wxbase dependencies in bitcoind.
i replaced the ugly default orange and blue theme with the frostee theme, which was the only decent looking theme i could find after extensive searching.
i request that derivative works be made public domain.
i reuploaded the changes.
i see a way that could happen on a long operation such as the initial download.
i see bitcoin as a foundation and first step if you want to implement programmable p2p social currencies like marc's ideas and others discussed here.
i see it calls gtk-init-check in wxapp::initialize.
i see openoffice.org and a number of other things on my computer do it that way.
i see the problem.
i see what happened.
i see what you mean about the password feature being useful to address that argument.
i see, that would happen with multiple nodes using the same nat or vpn or some isp that funnels everyone through a few proxy servers.
i sent the executable as an attachment in the previous e-mail, but if the mail server didn't let it through (it's 12mb), you can download it here: in the debug.log, it requests the block list, receives the block list, then begins uploading the list of blocks requested.
i sent you the main files.
i set the working directory to where the exe is since that's where debug.log is created, otherwise windows puts it in some weird directory.
i shied away from "transfer" because that sounds too close to sending a transaction.
i should add a command to timestamp a file that way.
i should add a special case to createtransaction to handle this.
i should be able to point forum.bitcoin.org to it.
i should probably change the scanhash_ functions to use pdata instead of pdata + 64 so they're consistent.
i should put some text in the transaction details (when you double click on it) explaining how it works.
i should research drupal and other cmses and see what's the most popular.
i should see if i can upgrade mingw to 4.3.x to get them on a level playing field.
i shouldn't have said "prime numbers".
i split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure ui.
i started posting in the other topic but i'll repeat here, this thread seems more specific to the topic.
i still have more testing to do.
i still haven't figured out how you managed to get a read exception rather than a write exception when your disk filled up.
i still like your bitweaver one better, i recreated it with text as a placeholder for now.
i still need to post the announcement message on the forum and mailing list.
i still prefer main.cpp.
i stripped it down to just sha and 11 general dependency files.
i suggest you wait before contacting any more payment processors.
i suppose if a socket fails and the os closes it then there's nothing left to remember it was non-blocking, but then accessing a closed handle should return immediately with an error.
i suppose it might be possible to measure cpu power for instance, if the cpu power challenge was only run for an average of 1 minute every 10 minutes.
i suppose it needs twice the resolution icon to fill the size of the upper left corner icon.
i suppose next to the send button, there would by a receive button, you press it and it says "here's a new address to use, here's the button to copy it to the clipboard, do you want to label it?"
i suppose the dialog could make it worse by giving people a chance to experiment with breaking it up.
i suppose the irc server probably limits accounts to one login, or some admin might not like to see a dozen logins on the same account.
i suppose they might have added exists recently, using get before that.
i suppose we could easily preprocess json reading the config file one line at a time, truncate the lines at any # character (and/or "//"?
i sure would.
i suspect bitcoind will probably work fine, but i hope you can still debug the problem.
i suspect reading all the prev txins is what's slow.
i suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower.
i suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
i take it you haven't received anything from that donor yet?
i tend to keep editing and correcting for some time afterwards, so if they want to update, they should wait.
i test compiled mingw, vc and ubuntu.
i tested it on a slow 7 year old drive, where bandwidth and cpu were clearly not the bottleneck.
i tested this with a non-lower-ascii account name on xp and confirmed the bug, then tested that the new getdefaultdatadir fixed it.
i think all it needed was a little testing time and to install the new icon xpm.
i think all the problems are in the ui.
i think an external miner could call getwork on both programs and combine the work.
i think blank account name ("") will be your default account.
i think everything is complete.
i think for modest amounts, almost everyone would refuse on principle alone.
i think gcc 4.3.3 on the linux build optimized the sha-256 code better than the old gcc 3.4.5 on windows.
i think he had it working on freebsd, but he wanted a non-ui version.
i think i know what happened.
i think i may have weakened the reconnect speed in test2.
i think i was wrong about wiki.
i think i'll just get rid of it.
i think i'll move debug.log and db.log into the same directory as the data files (%appdata%\bitcoin), rather than whatever the current directory happens to be.
i think i'm almost ready to check everything in.
i think i've got the peer networking broadcast mechanism covered.
i think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do.
i think in 5 or 10 years, the bandwidth and storage will seem trivial.
i think it must be wine related.
i think it should be lowered to 50kb per block.
i think it should just add it automatically.
i think it would be an improvement not to count one's own blocks as confirmations.
i think it would be possible for bitdns to be a completely separate network and separate block chain, yet share cpu power with bitcoin.
i think it's essential for a program of this nature to be open source.
i think it's going to be fine.
i think it's pretty clear that core 2 and lower are slower, i5 faster.
i think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.
i think most p2p networks can be dos attacked in numerous ways.
i think most projects go by real names for consistency.
i think our problem may be that we have forum notifications on, like e-mail you when you receive a pm, but we don't have e-mail verification of new accounts.
i think that's a really good idea.
i think that's the best option right now.
i think the case will be the same for bitcoin.
i think the most user friendly way of doing auto-run is putting an icon in the startup folder.
i think the only bug left is where the status number is mashed up.
i think the only thing i had to do was rename make*.exe something to make.exe.
i think the people who want anonymous will still figure it out without us trumpeting it.
i think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value.
i think they expect you to install a package during setup, but bitcoin doesn't have a setup.
i think they mean it's like this, but i'm not sure: i can't remember where i think i saw that it's supposed to send back http status 500 for an error reply.
i think they're used more by people who don't have the credit history to get a real credit card, so they buy gift cards themselves to pay for things that require a credit card.
i think this is a good compromise short of making the default fee 0.01.  it's not so much to ask that free transactions can only be used to turn coins over so often.
i think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
i think we better strip whitespace at the beginning and end of the key and the value.
i think we can do that.
i think we can make it local-only by binding to localhost only, so it can only be accessed through the loopback.
i think we should allocate $1000 at this point to your exchange.
i think we should de-emphasize the anonymous angle.
i think we'll get flooded with newbies and we need to get ready first.
i think what i usually see is like: is there a settings file thing in boost?
i think you do it like: if bytereverse((unsigned int*)hash[6]) < (unsigned int*)target[6].
i thought about that but there wasn't a practical way to do smaller increments.
i thought about what might cause the problem you're having and made a change that this build includes.
i thought i'd been careful not to accept any of the updates.
i thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger.
i thought it would be in there somewhere.
i tried to put them out of harm's way by putting them in the database subdirectory.
i trust him, he's responsible, professional, and technically much more linux capable than me.
i updated 32, 48 and the full size.
i updated the first post with a link to rc2 for linux with the fix for this.
i updated the first post.
i updated the svn with changes to support translation.
i updated them to 0.3.0. i am tempted to remove the download links from the other languages and only keep it on english.
i uploaded 0.3.0 beta to sourceforge and updated the links on bitcoin.org.
i uploaded a redesign of m0mchil's getwork to svn rev 189 (version 31601) m0mchil's external bitcoin miner idea has solved a lot of problems.
i uploaded an updated bitcoin.po for 0.3.1 attached to this message: please use it if you're starting a new translation.
i uploaded it to svn to go in with the 0.3 release.
i uploaded my json-rpc and command line implementation to svn.
i uploaded the 93% complete dutch translation to svn.
i uploaded the change to svn.
i uploaded the changes to svn rev 158.  i will post a 0.3.13 rc shortly.
i uploaded the changes.
i uploaded the mod but some files need to be chmod 777 so it can install.
i uploaded these to the svn.
i uploaded this change to svn rev 156.  the switch to enable is "-allowreceivebyip".
i uploaded this fix to the svn.
i uploaded this makefile.osx change to svn.
i uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to sourceforge and updated the links on the homepage.
i urge you not to use bdb 4.8.  the database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.
i used a different name for the switch because "-allowiptransactions" sounds like it includes sending.
i usually shy away from iostreams.
i very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message.
i want something that will be easy for a variety of server side languages to call, particularly php.
i want the release builds to have sse2.
i want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address.
i want to add the backend support for .onion addresses and connecting to them, then go from there.
i want to avoid #ifdefing up the code if we can.
i want to design the api carefully.
i want to pre-announce some of the features in version 0.2 on the forum and try to get some anticipation going.
i want to use ssl for the connection, using the bitcoin address' public key as the cert.
i wanted to clean up the interface a little.
i wanted to let you know, i just released the full implementation of the paper i sent you a few months ago, bitcoin v0.1.
i wanted to pick something that would make prices similar to existing currencies, but without knowing the future, that's very hard.
i wanted to take another fresh look at them in case i think of any better function names before committing.
i wanted to thank you for posting about bitcoin on your blog a year or two ago, back when i announced it on the cryptography mailing list.
i was able to get it to work in simple tests on windows, but not when linked in with bitcoin.
i was going to post details of the plans for escrow, but since getting slashdotted i haven't had time.
i was not able to find any table of family, model and stepping numbers for cpus.
i was not able to reproduce this.
i was researching config file formats, here's a comparison.
i was starting to post the same idea you said nelisky.
i was talking about in the hypothetical system i was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.
i was temporarily able to reproduce the bug and narrowed it down to the "mapaddresses.count" in the following code.
i was trying to follow the 1.0 spec: it called for multiple invocation.
i was trying to take the safer option.
i was very interested to read your b-money page.
i wasn't expecting that.
i wasn't satisfied with my custom2 theme.
i went about 200 blocks back.
i went ahead and put the new drupal site online.
i went in and granted us access using the alternate account.
i went with the single-library compile of wxwidgets since we're linking to almost every library anyway.
i will implement a feature to stop accepting inbound connections once you hit a certain number.
i will need to prepare the code for translation first.
i will probably relent and do that.
i will recompile the 64-bit part of the linux 0.3.8 release.
i will soon make the "your bitcoin address:" window automatically change whenever you receive anything to the address displayed.
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.
i wish rather than deleting the article, they put a length restriction.
i wonder if any json-rpc package even supports multiple invocation, probably not.
i wonder if that extra memory is just disk cache or something.
i wonder if the database dat files are interchangeable with windows.
i wonder if the status of blocks should say "#/unconfirmed" all the way up to maturity (119/unconfirmed then 120 blocks) instead.
i wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?
i wonder if we could get away with applying for one account and then everyone use the same account?
i wonder if we need admin privilege and don't realize it.
i would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet.
i would be surprised if 10 years from now we're not using it could get started in a narrow niche like reward points, that won't inevitably get dumbed down when the trusted third party gets cold feet.
i would like to have a single executable that can also run on a ui-less system, but i'm not sure how on linux to link to things but still be able to run and not use them if the library is not present.
i would make this release version 1.3. the first panel of the status bar is shared with the help description of menu items as you hover over them.
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.
i wrapped sha256.cpp in try it now.
i wrote what i did and switches i used in build-unix.txt.
i'd also like to know if it runs fine as long as you don't turn on generate.
i'd better install 64-bit then.
i'd consider turning off the forum notification e-mails, i don't know why we have that.
i'd like to look at your current debug.log file and try to understand what's going.
i'd like to release it soon.
i'd rather call an existing file copy function than make and test my own.
i'd rather have command line control, that would get us remote admin and batch automation.
i'd rather keep the makefile simple as long as possible.
i'd rather put it off a while longer.
i'd rather you didn't make a build of the 1000 node connecting version available.
i'll add it to the list.
i'll add that next time i update svn.
i'll always announce new versions there.
i'll ask him to do this version.
i'll build releases shortly.
i'll change it back.
i'll change it to 1000 next time.
i'll convert the criticalsection code to wxcriticalsection and upload it to svn (it's a little tricky).
i'll create new ones as the need arises.
i'll delete the file once the release is ready.
i'll do a more thorough forced shutdown later.
i'll fix it.
i'll forward the release introduction in the next message.
i'll get started on adding the password field.
i'll give the original when i'm finished.
i'll go ahead with setting up drupal then.
i'll have to do another stress test before release.
i'll have to work on figuring out what's getting hung up.
i'll keep trying and try to get you that logo stats thing.
i'll let him know it was received and thank him.
i'll post larger sizes and full size a little later.
i'll post tor instructions at that time.
i'll probably enable multi-proc generating support, and hopefully make it safe to just backup wallet.dat to backup your money.
i'll probably end up doing that instead of the code below.
i'll research what people say about the two.
i'll see if i can figure out how to temporarily move drupal aside to drupal.php or /drupal/ or something where we can still easily get in and work on it.
i'll see if i can get a newer version of mingw.
i'll send you the debug builds shortly.
i'll shorten that length of time in a future version.
i'll start researching this.
i'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.
i'll try the startup folder code and see if i can reproduce the problem.
i'll wait another 12 hours and then change the forum tab on bitcoin.sourceforge.net to go to http://www.bitcoin.org/smf/ for future reference, the changes in smf to update the base url were: server settings-   themes and layout-   there's a path in smileys and message icons the bitweaver menu editor is broken, i can't change the forum link.
i'm also curious if it performs much worse on 32-bit linux vs 64-bit.
i'm also curious if it's a little faster on linux than windows.
i'm also implementing the orderly initial block download.
i'm also recommending this approach for the implementation of web apps.
i'm attaching a dbg exe you can try that deletes the line of code and turns off optimization.
i'm attaching bitcoin20x20.png, the 20x20 version with full transparency.
i'm attaching the msvc debug version in case you need it.
i'm attaching your russian one to this message.
i'm currently leaning towards json-rpc.
i'm currently using wxwidgets 2.8.9 for now because it's the same version as on windows and i don't want to wonder if there's version change issues at the same time as platform change.
i'm currently using: -daemon (or -d)   (enables rpc and runs in the background) -server           (enables rpc) this is working.
i'm disabling the wallet flush feature on linux.
i'm glad they got that so everyone doesn't have to build wxwidgets themselves.
i'm going to hide the transaction fee setting, which is completely not needed and only serves to confuse people.
i'm going to start reading on xml-rpc.
i'm going to test this some more before sending test8.
i'm guessing the problem is incompatibility between the type "unsigned int" and the type of str.npos, which is size_type.
i'm happy if someone with artistic skill wants to contribute alternatives.
i'm kind of surprised there was a crash, i've tested heavily and haven't had an outright exception for a while.
i'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.
i'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in boost if it has it.
i'm looking forward to trying upnp.
i'm losing my mind there are so many things that need to be done.
i'm making some changes.
i'm more inclined to disallow notifications or anything where the forum sends you e-mail.
i'm more likely to see bugs posted in the forum, and i think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker.
i'm not able to reproduce it anymore at the moment.
i'm not arguing that this is the permanent way of things forever.
i'm not completely sure if it's preinstalled by default.
i'm not going to be much help right now either, pretty busy with work, and need a break from it after 18 months development.
i'm not grasping your idea yet.
i'm not in a big hurry to fix this because i can't think of any benefit to having more than one incoming connection port.
i'm not really a fan of that type of forum layout.
i'm not sure __wxmac__ is the right define.
i'm not sure but i think they may want to use different passwords for the two.
i'm not sure exactly how to describe it (that would fit on the status bar in 1 word, maybe 2 words max), any ideas?
i'm not sure how available it is, but i think intel used to have a profiler for profiling on a per instruction level.
i'm not sure how it works out the password for access, maybe it's just based on being logged in to sourceforge.
i'm not sure how that could be implemented though.
i'm not sure how the 200kb/sec, since it waits at least a half second between connection attempts.
i'm not sure if always signing a different blinded public key would already give you this property.
i'm not sure if i want it to be something that can be accessed across the network.
i'm not sure there's a lightweight easy to build library we can integrate into our project.
i'm not sure they had wxpack before.
i'm not sure what the interface could be, maybe: listtransactions <json null type> [count] it would be hard to do that from the command line though.
i'm not sure what the licensing issues would be.
i'm not sure what those lib errors are, i'll do some searching.
i'm not sure what to call it, but we could use a post that lists these things users should know.
i'm not sure where exactly to fit that in, but it could certainly calculate the expected average time between blocks generated, and then people would know what to expect.
i'm not sure why, i have to suspect it's a utf-8 thing, but no idea how that could happen.
i'm pretty sure there's a notification option for when you receive pms, but i don't see a way to disable it.
i'm pushing some other misc changes out of the way first, then i'll upload the patch for this.
i'm really always going to need it.
i'm really dismayed to have this botch up the release after all that stress testing.
i'm running a stress test that continuously generates a lot of activity and db access and never got it.
i'm still editing it a little more and then i'll e-mail it to bitcoin-list and send it to the cryptography list.
i'm still merging in some changes i had that need to go in before any next release.
i'm still thinking about how best to structure the management interface.
i'm sure everyone who's written an internet app like a browser or p2p app had to slog through all the ways the internet can trash you.
i'm sure google groups is a lot easier to post to.
i'm sure that in 20 years there will either be very large transaction volume or no volume.
i'm surprised this one isn't using usenet, although it is kind of difficult to get access to post to usenet in an automated way these days.
i'm the one who's going to be fixing it.
i'm thinking a new function getaccountaddress instead of overloading getnewaddress: getaccountaddress <account> gives you an address allocated from getnewaddress <account>.
i'm thinking i should move the ui in the direction of having the user ask for their bitcoin address when they want one.
i'm thinking it wouldn't make sense to make an ebay type site until later.
i'm thinking of merging the bitcoin.org information with your site content so i can switch the whole bitcoin.org domain over.
i'm thinking phpbb or ipb or similar.
i'm thinking we should disable it again on linux.
i'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
i'm using boost::asio for sockets.
i'm waiting to post on the forum when i've had more time to think about the commands.
i'm working on getting version 0.3 released as soon as i can.
i've always hated projects with a lot of big dependencies, but there's no avoiding it, each one is essential.
i've attached a copy of the debug runtime dlls.
i've attached bitcoin.exe with symbols.
i've been able to reproduce the db::open/close exception 3 times now on 32-bit linux by hitting it with a continuous flood of non-stop requests.
i've been configuring the smf forum.
i've been meaning to redo it.
i've been researching options for interprocess calling.
i've been running my stress test on it and it's functioning normally.
i've been testing on xp sp2, maybe sp3 is something.
i've been thinking about that for a while.
i've been working on getting my linux machine set up and building the dependencies.
i've been working on writing the alert system.
i've coded it so you can pay any optional amount of transaction fees you want.
i've developed a new open source p2p e-cash system called bitcoin.
i've done a careful scrub to make sure it doesn't use dns or do anything that would leak your ip while in proxy mode.
i've done as much as i can with css, the rest requires editing php files and uploading images.
i've done test builds with 2.9.0 and there is one bug left to fix.
i've dropped the db_private flag in rev 153. added in svn rev 152 the fix is in svn rev 151. you will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.
i've had some ideas that could only be done before an exchange exists.
i've never gotten them.
i've never had select fail before.
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've never seen that fail before.
i've noticed that hashing performance doesn't vary as much between cpus as you'd expect.
i've only tested this moderately.
i've seen other projects that use the wiki for the faq or even the whole site.
i've seen projects that have major following just from forum talk and pie-in-the-sky planning without even having any code yet.
i've thought about pow on transactions many times, but usually i end up thinking a 0.01 transaction fee is essentially similar and better.
i've thought about ways to do a more cursory check of most of the chain up to the last few thousand blocks.
i've tried to be as portable as possible and use standard c stuff instead of windows calls.
i've wondered about that for a long time, but i didn't think it would be possible due to addition carrying into the neighbour's value.
ideally, it should be mit license or public domain.
identities are not used, and there's no reliance on recourse.
ie 6 on xp anti-aliases, and versions below that have less than 1% market share.
if 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.
if 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost.
if a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is: 1) show it the entire history back to the original generated coin.
if a greedy attacker is able to assemble more cpu power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins.
if a majority of cpu power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.
if a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do.
if a no-fee block has already been generated and hasn't helped, then i need to look at what's wrong.
if a node does not receive a block, it will request it when it receives the next block and realizes it missed one.
if a node requires a higher fee, that node would be passing up all transactions with lower fees.
if a nonce is found, patch it into data and call getwork.
if a solution was found, a much better, easier, more convenient implementation of bitcoin would be possible.
if all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together.
if an analytical attack helps you find an input to ripemd-160 that produces a collision, what are you going to do with it?
if an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again.
if an option needs a list or more structured data, it could always parse its value as json: although it has to be all on one line then.
if anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.
if anyone wants more than 8 connections, they can open port 8333 on their firewall.
if at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it.
if bandwidth is a problem, delete my link in the "0.3 almost ready" thread.
if bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
if bitcoin catches on on a big scale, it may already be the case by that time.
if bitcoin is running then you have to backup the whole %appdata%\bitcoin directory including the database subdirectory, but even if it's not running it certainly feels safer to always backup the whole directory.
if bitcoin remains a small niche, it'll be worth less per unit than existing currencies.
if blocks is 10, then the highest block number you have is 10.  it means you have block 10 and you don't have block 11. it would reduce the confusion we had here: that's a difficult approach.
if connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.
if enough people think the same way, that becomes a self fulfilling prophecy.
if everyone bought faster machines, they wouldn't get more coins than before.
if everyone goes to tor, there won't be any nodes to connect to.
if free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.
if i can't think of anything else, i can always shut down and restart sockets if it gets hosed like that.
if i get a chance i'll try -m64 and see what the problem is.
if i increased it to every 10 minutes, it would still be a small enough presence in the log file.
if i made a bitcoin payment integration for this, would anyone be interested in running it?
if i recall correctly, 500 is the prescribed status code for json-rpc error responses.
if i spawn a thread and do mapaddresses.count, even as the very first thing in the program, it segfaults.
if i try that it says "you don't have enough money" or "insufficient funds" from the command line.
if i'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system.
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.
if it can only be accessed on the local system, then local security authentication covers it, and it is incapable of being hacked remotely.
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.
if it did grow to consume significant energy, i think it would still be less wasteful than the labour and resource intensive conventional banking activity it would replace.
if it does, it'll be hard to overcome the presumption.
if it doesn't need the password, it should be fine.
if it finds a bad one, it sets all that chain's bnchainwork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg.
if it gets "433" name already in use (it was error 433, right?
if it gets tiresome working with small numbers, we could change where the display shows the decimal point.
if it happens gradually, we can still transition to something stronger.
if it is, then i'm thinking that any amd that supports 64-bit has 128-bit sse2.
if it jumbles the order of the .po file then i can't diff for changes.
if it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before.
if it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad.
if it sees a longer chain, but it can't process it, then it knows something is wrong.
if it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long.
if it was closed source, nobody could verify the security.
if it was doing that it would be much slower.
if it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source?
if it weren't for those, it would be able to reorg all the way back to the first block.
if it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.
if it's going to get broken, it'll be by some breakthrough cracking method.
if it's impossible to communicate from one side to the other, how are you going to put a spend on each side?
if it's scattered and less than 25%, just random bad luck.
if it's summer and you're using a/c, then it's twice.
if it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15kb per sec (120kbps), or something else is wrong.
if it's too slow, we could have it only go back to a certain block number.
if it's website access, typically it wouldn't be a big deal to let the customer have access for 5 minutes and then cut off access if it's rejected.
if it's wrong, you can still override it with -4way or -4way=0.
if necessary i can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.
if none did, it'll warn you in the description: "generated - warning: this block was not received by any other nodes and will probably not be accepted!"
if not, i think that's where group signatures comes in.
if not, there are ways a google group could help, if it really came to that.
if one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
if one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit.
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 someone digs through the transaction history and starts exposing information people thought was anonymous, the backlash will be much worse if we haven't prepared expectations by warning in advance that you have to take precautions if you really want to make that work.
if someone diverged from the formula, their block would not be accepted by the majority.
if someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up bitcoin and give out the ip address on their website.
if someone famous is getting more e-mail than they can read, but would still like to subscription sites that need some extra proof-of-work for their give out the ip address on their website.
if someone has other motives to prove a point, they'll just be proving a point i already concede.
if someone has time to write it, here's the list: - make sure your clock is set correctly.
if someone installs a keylogger on your computer, they could just as easily get your bank password and transfer money out of your account.
if someone was getting ready to fork a second version, i would have to air a lot of disclaimers about the risks of using a minority version.
if something is not famous enough, there could at least be a stub article identifying what it is.
if something substantial is discovered, then we can work out the particulars.
if that doesn't work and you just want to get it working, you could edit wxwidgets include/wx/arrstr.h, line 167 and comment out the wxassert_msg.
if that doesn't work, there's now the catch-all solution: another thread monitors the send/recv thread and terminates and restarts it if it stops.
if that works, it doesn't have to resort to terminating.
if that's a concern, sending to a unsigned cleartext e-mail, which is already vulnerable to type 1 a small privacy tradeoff.
if that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.
if the best library is mit, boost, new-bsd or public domain, then we can stop re-writing it.
if the give any other identifying information about the recipient, so certainly implement that.
if the hash breakdown came gradually, we could transition to a new hash in an orderly way.
if the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.
if the item never comes through after a timeout, they request it from another neighbour that had it.
if the majority were based on one-ip-address-one-vote, it could be subverted by anyone able to allocate many ips.
if the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.
if the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes.
if the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks.
if the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.
if the only library is closed source, then there's a project to make an open source one.
if the only library is gpl, then there's a project to make a non-gpl one.
if the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction.
if the previous run was stopped by crashing or killed, that would be the wrong thing to do.
if the price is above cost, profit can be made by generating and selling more.
if the price is below cost, then production slows down.
if the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent.
if the recipient is not online, it is possible to send to their bitcoin address, which is a hash of their public key that they give you.
if the recipient is online, you can enter their ip address and it will connect, get a new public key and send the transaction with comments.
if the same chain contains both spends, then the block is invalid and rejected.
if the same code was in the shortcut one, maybe that was the problem.
if the same money gets sent again, it won't incur the fee again.
if the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.
if the seller doesn't send the goods, he doesn't get paid.
if the sellers can get lr for bitcoins, they're happy, and that may be subsidized at first by investors who want to buy bc in large lots.
if the system let users configure the minimum payment they're spam called "dusting".
if the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam.
if the thief gives it back, it turns to gold again.
if the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it.
if the website and forum switch at the same time, then forum.bitcoin.org isn't necessary unless we want it that way for looks.
if there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.
if there is a desire to take up a form of money that can be traded over the internet without a ttp, then now that is possible.
if there is a problem, it could easily be solved by deleting your block files, as follows: it'll then re-download the block chain.
if there is a way to lose unconfirmed blocks, it would have to be the database errors.
if there is a way, then probably someone else is also using it to flow the block chain over.
if there is an alert, the following json-rpc methods return an error: the remaining 14 methods function as normal.
if there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.
if there was a collision, the collider could spend any money sent to that address.
if there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
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?
if there's a better name for the switch, we can change it again.
if there's a way to prohibit the forum from sending e-mail notifications, maybe we should do that.
if there's going to be a message system, it should be a separate system parallel to the bitcoin network.
if there's something else each person has a finite amount of that we could count for one-person-one-vote, i can't think of it.
if they can get a magazine or newspaper to publish their hashes, it would work a lot easier in court for their purposes.
if they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.
if they can, then they know everything.
if they give it back, you can re-activate it.
if they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.
if they pay 1 or 2 cents transaction fees, they pay for themselves.
if they really want to optimize, and it's a large download, they could cancel the download in the middle if the transaction comes back double-spent.
if they run it and get no connections, they'll probably just give up.
if they're generated too fast, the difficulty increases.
if this doesn't work, i guess i'll look at the sourcecode of some other p2p apps like bittorrent and see how they deal with this stuff.
if this is ubuntu, if you get wxwidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly.
if three sse2 units is excessive, then hyperthreading would help keep them all busy.
if transaction confirmations become slow, you can get priority by using "-paytxfee=0.01".
if two developers can fork bitcoin and succeed in redefining what "bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then i will have no choice but to declare bitcoin a failed project.
if two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.
if we get it working on linux, i'll run my test suite against it here off-network first, then we can give an unreleased build to libertystandard to test for a while before going public.
if we get too big, then by the same token, we're big enough that we don't need irc anymore and we'll get off.
if we go with self parsed, that doesn't mean we can't use json on particular parameter values as needed.
if we have to, i guess we could edit the php code.
if we hit the threshold now, it would almost certainly be some kind of flood and not actual use.
if we needed to, we could have a bittorrent-esque tit-for-tat for transaction broadcast.
if we only have default captcha, we'd be getting flooded with spam accounts.
if we request to get off of pbl, we'd better make sure we've got the problem secured first.
if we see a weakness in sha256 coming gradually, we can transition to a new hash function after a certain block number.
if we started getting dos attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.
if we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2mb per year.
if we use the syntax: ...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 went to all the work of implementing ssl, only large storefronts usually go to the trouble of getting a ca cert, but most of those cases would still be better off to use bitcoin addresses.
if we were to have one, we would have to make a thoroughly researched choice.
if we're not closing and opening all the time, the error shouldn't get a chance to happen.
if we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as: - the value - the association of inpoints and outpoints in one transaction the network would track a bunch of independent outpoints.
if you actually did restore an old wallet.dat, i think you may have to delete blk*.dat to rediscover your own transactions during the redownload.
if you already have a po file, poedit can update it.
if you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions.
if you build rev 134 on linux now you'll get the -4way switch.
if you built it, i wonder why it would put itself in a different place.
if you can accept incoming connections and you have a static ip address, post it here!
if you can figure out how to make it so regular users can edit things, then anyone who wants to can help.
if you can figure out what the problem was and shut it down, then after you're sure it's fixed, request pbl to take us off the block list.
if you can find sha256 code that's faster (with mingw/gcc) than what we've got, that would be really great!
if you can install phpbb3 on your vps, that's probably the better option.
if you can write a faq, i can give you a compilation of my replies to questions in e-mail and forums for facts and details and ideas.
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.
if you can't upgrade to 0.3.6 right away, it's best to shut down your bitcoin node until you do.
if you connect to freenode's hidden service, then they tell you they've also banned tor from that due to abuse and it kicks you off.
if you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
if you copy your wallet file to a second computer, then they both think the money in the wallet is theirs.
if you could send me the code, i'd like to take another look and see if i can see what the problem was.
if you create a www.bitcoin.org/zh/ copy of the site and give him an account with just the ability to create new pages and edit text, he'll probably translate the site into chinese for you and maybe maintain it.
if you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.
if you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that ip would just say it couldn't connect to the recipient and nothing is sent.
if you do it yourself, please still give me access to httpd.conf in case i need to change it again later.
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.
if you do, i think it should be a very brief, single paragraph article like 100 words or less that simply identifies what bitcoin is.
if you do, please tell me how it goes.
if you don't believe me or don't get it, i don't have time to try to convince you, sorry.
if you don't have enough money with the fee added, it says "total exceeds your balance when the # transaction fee is included  " does anyone want to translate the bitcoin client itself?
if you don't mind, could you keep the old blk*.dat files for a little while in case i need to look at them?
if you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
if you doubleclick on the transaction you get a little more information.
if you downloaded the blk*.dat files from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself.
if you ever find anyone who turned it on.
if you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.
if you find a security flaw, i would definitely like to hear from you privately to fix it before it goes public.
if you find any, then check for any errors right after that.
if you find it for me, it's more likely i'll get to implementing it.
if you get another crash in wine and it prints anything on the terminal, e-mail me and i may be able to figure out what happened, maybe something i can work around.
if you go to admin-apply mod, it offers to do it automatically if you enter an ftp login.
if you got 22dbrunrecoveryexception and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000* windows and linux users: if you got 0.3.5 you still need to upgrade to 0.3.6. svn is updated with version 0.3.6. uploading windows build of 0.3.6 to sourceforge now, then will rebuild linux.
if you gpl stuff, i have to avoid using it.
if you had more than, say, 4 in a row, that would be abnormal and probably a loss of network communication.
if you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
if you have 2 or 3 connections, you're fine.
if you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left.
if you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
if you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.
if you have any trouble with it, send me your debug.log file.
if you have better values, suggestions welcome.
if you have code that checks the error and expects a string, you'll need to change it.
if you have gdb, you could run it in gdb and do a backtrace.
if you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard.
if you have many computers, then using the -connect switch on most of them to connect locally makes more sense.
if you have other cheaper heating than electric, then the waste is only the difference in cost.
if you have problems building because of it, then edit makefile.unix and: - remove -dfourwaysse2 - remove obj/sha256.o from the end of these lines: bitcoin: $(objs) obj/ui.o obj/uibase.o obj/sha256.o bitcoind: $(objs:obj/%=obj/nogui/%) obj/sha256.o the 0.3.10 linux build have the -4way option when i build it.
if you have two computers, unplug the internet and use "bitcoin -connect=<iplinux.
if you imagine it being used for some fraction of world commerce, then there's only going to be 21 million coins for the whole world, so it would be worth much more per unit.
if you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in "bc" don't land square on a pixel.
if you mean for users, that's why we static link it.
if you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap.
if you need to transfer between two copies, you could send it to the other's bitcoin address.
if you only buy bitcoins, then you're only sending money out not taking people's money, that would still be useful to peg the currency.
if you only had one connection, what if that node is slow or busy, or only connected to you?
if you only have 24k blocks, it must not have finished the initial block download.
if you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.
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.
if you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under.
if you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.
if you read it into memory and write it out, it could fail in tight memory situations.
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 run a computational task 24/7, not letting it idle, it uses significantly more power, and you'll notice it generates more heat.
if you run it again and it still doesn't download blocks, keep it running for several hours at least and then send me the debug.log.
if you sell something to a user, you could do move "theiraccount" "" 123.45. is "move" the best name for this?
if you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it.
if you send by ip, the recipient sees you because you connect to their ip.
if you solve it, it will solve a block from both bitcoin and bitdns.
if you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty.
if you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less.
if you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.
if you still suspect this code, for testing you could change it to: const char* wxgettranslation(const char* pszenglish) could you send me the debug.log?
if you think about it, just because it's implemented in hardware doesn't mean it's crazy fast.
if you touched the file, that sounds like something is there.
if you try the software, e-mail me your bitcoin address and i'll send you a few coins.
if you turn off generate coins, does the cpu usage go flat?
if you use a privacy proxy, man-in-the-middle risk is unacceptably high.
if you want to have an e-mail address listed, i'll make an image out of it so it doesn't attract spam.
if you want to test for any gui mac port under os x, use __wxosx__.
if you want to test for any port under mac os x, including, for example, wxgtk and also wxbase, use __darwin__" there would be a command line switch at runtime to tell it to run without ui.
if you want to try it, pm or e-mail me your e-mail address where i can send it as an attachment and also what os (win, linux 32-bit, linux 64-bit).
if you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.
if you were able to delete a bitcoin address and someone sent to it, the money would be lost.
if you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.
if you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block.
if you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.
if you're copying blk*.dat from another computer of yours, that should be fine.
if you're going to have more than 8 lan nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections.
if you're in the smaller segment, you should assume nothing is confirmed.
if you're interested, i can go over the ways it would cope with extreme size.
if you're only going to have one person work on building the block, that could take days.
if you're providing one incoming port, then you've done your bit to help the network.
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.
if you're running the linux build right now, it would be interesting to see what the log says on your side.
if you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.
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.
if you're selling something that doesn't merit a network-scale attack to steal it, in practice you could cut it closer.
if you're serious about privacy, tor is an advisable precaution.
if you're set up to build, please test it.
if you're still worried about it, it's cryptographically possible to make a risk free trade.
if you're thinking of it as a cpu-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.
if you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems.
if you're using another port, it would assume it might be a regular old normal proxy and would keep retrying irc at longer and longer intervals.
if you're using electric heat where you live, then your computer's heat isn't a waste.
if you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.
if you're worried, maybe there's a way to lock just the english version of the homepage.
if you've accumulated several errors in db.log, could you send it to me?
if you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such: bitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress> if someone running a node with a static ip address that can accept incoming connections could post their ip to use for -addnode, that would be great.
if you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.
if you've ever been connected before, you don't need irc to bootstrap anymore.
if you've found a signed int somewhere, please tell me (within the next 25 years please) and i'll change it to unsigned int.
if you've generated 50000 btc, then you already have 1000 own addresses, one for each 50 generated.
if you've got it working already, stay with 0.3.0. 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.
if you've port-forwarded though, then outside nodes might still connect inward to you.
if your block does not link to the latest block, it may not be accepted.
if your connections go dead again, it should disconnect and reconnect them.
if your router can change the port number when it forwards, you could allow more than one client to receive.
if yours is faster with -4way, then i should change it to always use sse2 with any amd with 64-bit.
imagine if gold turned to lead when stolen.
imagine someone stole something from you.
imagine you have to run your computer 24/7 for a month to generate 1 cent.
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 please do these tests on the test network.
important to remember, even if bitcoin caught on at dot-com rates of growth, it would still take years to become any substantial fraction of all transactions.
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.
in a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.
in a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin.
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.
in any case, any payment processor is going to expect you to be selling something real.
in bitcoinminer, we format the buffer once and keep reusing it.
in case you still need it, here's the accounts and passwords for mysql.
in cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade.
in concept, they're tied together by a merkle tree.
in fact, bitcoin does not use reputation at all.
in general, sending by ip has limited useful cases.
in its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.
in later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around.
in many of the contexts of this rpc stuff, you can print to the console with fprintf(stdout, like this: boost::program_options has the same "key=value" format.
in our case, it is cpu time and electricity that is expended.
in particular, -addnode is needed if you're always going to connect through tor, since the irc server blocks all the tor exit nodes.
in practice, many would be burning off excess allocated bandwidth or unlimited plans with one of the cheaper backbones.
in practice, splits are likely to be very asymmetrical.
in practice, to retrofit it for bitcoin, the bitdns side would have to have maybe ~200 extra bytes, but that's not a big deal.
in response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade: if you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.
in script languages like php and python the syntax is as natural as calling a local function.
in some cases, i'm still thinking about the best design for the fix.
in some countries, they're called gift cards, and can be used wherever credit cards are accepted.
in storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.
in support of the priority feature, selectcoins only uses your own 0 conf transactions only as a last resort if that's all you have left.
in test3 i'm making it more determined to reconnect quickly.
in that case, domain objects (domaincoins?)
in that case, everything that's been implemented up to now would be implemented exactly as it has been.
in that case, it might manifest as a similar exception again, or if your block count in the status bar stopped going up, that would also indicate a problem.
in that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days.
in that case, login integration with the forum doesn't matter much.
in that case, they work on the first one they received, but save the other branch in case it becomes longer.
in that case, you wouldn't want the -connect computers on irc.
in that sense, every node serves as a directory server.
in the "no password is set" warning, it could tell you where the file is and what to do.
in the absence of a market to establish the price, newlibertystandard's estimate based on production cost is a good guess and a helpful service (thanks).
in the bitcoind build, we don't link ui.o or uibase.o.
in the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent.
in the design it was necessary for it to switch to a longer chain no matter how far back it has to go.
in the design pdf it's called simplified payment verification.
in the early days there were some steady supporters, but they all had pool-allocated ips that change every few days.
in the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.
in the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.
in the following cases, would case 1 flush once and case 2 flush twice?
in the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
in the meantime, sites like have been experimenting with account-based sites.
in the mint based model, the mint was aware of all transactions and decided which arrived first.
in the next release (0.3.13), i'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5.  the last number represents changes on the svn between releases and ought to be properly represented in the version number.
in the next release (version 0.2), the command line to run it through a proxy from the first time is: bitcoin -proxy=127.0.0.1:9050 the problem for tor is that the irc server which bitcoin uses to initially discover other nodes bans the tor exit nodes, as all irc servers do.
in the next svn rev, i'll make it only go back to the last checkpoint at block 74000.  if we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem.
in the svn version, if a transaction requires a transaction fee, it says "this transaction is over the size limit.
in the windows world, "unicode" means utf-16 (wchar).
in theory, the block download time should top out 8 months from now when moore's law will be growing faster than the block chain.
in this beta version, we haven't had time to try and tinker-proof it yet.
in this case, unfortunately, his wallet had a single 9000 btc bill in it, and it had to break it to get 1 btc and 8999 btc change.
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).
in this kind of escrow, a cheater can't win, but it's still possible for you to lose.
in this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.
in this way, the dos attack with an enormous fake block can also be prevented.
in this way, the proof-of-work should always be carefully verified before it„Ç‚†starts„Ç‚†the receiving process to prevent a dos attack against the network.
in windows, you select the process in the task manager, right click, set priority.
in wine, there's no way for the windows version to do so_reuseaddr, so that would add 60 seconds (on my system) of time_wait after the port is closed.
in your head, you do a probability estimate balancing the odds that it keeps increasing.
indeed, bitcoin is a distributed secure timestamp server for transactions.
indeed, it is much like pekunio in the concept of spraying redundant copies of every transaction to a number of peers on the network, but the implementation is not a reputation network like wizard rabbit treasurer.
independent networks/chains can share cpu power without sharing much else.
information based goods like access to website or downloads are non-fencible.
initial download took 1 hour 20 minutes.
initially it can be used in proof-of-work applications for services that could almost be free but not quite.
initially it can be used in proof-of-work applications it's sent directly when it connects.
instead of connecting by ip, we can connect to a domain name by ssl, using the existing ca infrastructure to authenticate that you're connected to the owner of that domain.
instead of fragmentation, networks share and augment each other's total cpu power.
instead of naively requesting all the blocks at once, it'll request batches of 500 at a time.
instead, all networks in the world would share combined cpu power, increasing the total strength.
instead, i added tor instructions at the bottom, with instructions for how to stay anonymous (pseudonymous) directly after the tor instructions: "if you want to remain anonymous (pseudonymous, really), be careful not to reveal any information linking your bitcoin addresses to your identity, and use a new bitcoin address for each payment you receive."
institutional momentum is to stick with the last decision.
int is good until 2106.  surely the network will have to be totally revamped at least once by then.
interesting, so how is the balance between purchases of coins and cash going?
interestingly, one of the e-gold systems already has a form of spam called "dusting".
internally, it could only be: 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.
ip addresses... much easier to get lots of them than cpus.
irc is a good directory server (i've heard it has other uses too), and there are mature irc server implementations available that anyone can run.
irc is completely redundant since 0.3.0. no, that's not what it is.
irc is really only needed to seed the first connection, but we've been using it as a crutch to get connected faster.
irc seems to be working.
irc servers ban tor because they have actual text chat on them... if there was one with just bots and junk then it wouldn't care.
irc was only intended as a temporary solution.
irc was still working, so it wasn't that you were offline from the internet.
irc.lfnet.org is pretty old and has impressive uptime.
ironic if we end up having to choose between economic liberty and conservation.
is anyone else running ok on windows 64-bit?
is it 2x fast on amd and 1/2 fast on intel?
is it about time we lose the beta?
is it just a matter of "sudo apt-get install libgtk2.0-0" and having some extra libraries sitting around?
is it one of those sub-languages like "nl-??"?
is it possible for the translators (at least the more trusted ones) to have user accounts on drupal so they can update their translated text directly?
is it possible windows could have 8% more overhead?
is it set to german, dutch or italian?
is that a problem?
is that an actual setting somewhere?
is that it?
is that right?
is that still starting from crypto++?
is that working better?
is there a chance the sse2 code is slow on intel because of some quirk that could be worked around?
is there a command line option to enable the sock proxy the first time that bitcoin starts?
is there a standard file extension?
is there a way to make bitweaver allow users to edit (and maybe delete) their own messages in the forum?
is there a way to open berkeleydb exclusive?
is there any chance of getting it to build the gui version also?
is there any traditional standard?
is there any way i can downgrade to an older version of gcc on 10.04?
is there anyone who wants to volunteer to run an irc server in case freenode gets tired of us?
is there anything in debug.log?
is there something in boost?
is there something like ipc sockets on windows?
is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?
is this a problem on linux, that if you build on the latest version, then it has trouble working on older versions?
is this an environment where you can build wxwidgets once and leave it there and just keep using it?
is this ok?"
is vc trying to use precompiled headers and screwing it up?
is your linux machine 64-bit or 32-bit?
isp network cuts are just your local area.
it adjusted to 181.54 a few minutes ago.
it already uses so_reuseaddr so it can bind to the port if it's in time_wait state after being closed.
it also has the advantage that multiple hits from the same user can be combined into one transaction.
it at least takes away the profit motive for cheating you.
it automatically sets its build configuration at compile time based on the compiler environment.
it breaks the lock in ssl mode with a mixed content warning, "partially encrypted" and "contains unauthenticated content".
it can already be used for pay-to-send e-mail.
it can be a no-op on linux.
it can be earlier than the previous block, but it must be greater than the median of the last 11 blocks.
it can be programmed to follow any set of rules.
it can be run in a few simple modes without access to the ui if you don't mind a minimized window on the desktop.
it can be safe if you're using it over your own lan, like if you have multiple servers at a location that talk to each other.
it can do is tell which of your addresses it was received on.
it can last several decades unless there's some massive breakthrough attack.
it can never be reliable that way.
it can operate entirely without irc if it needs to, but it's better having irc for redundancy.
it can reject the payment and return an error message if it doesn't contain a valid order number.
it can't "shut down the complete network".
it can't assume the file is smaller than memory, although it currently still is.
it can't be a whole sentence, unless we think of somewhere else to put it, but where would that be?
it can't be recorded until it locks.
it can't do arbitrary actions remotely.
it can't really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.
it compiled, but sha-256 didn't work correctly; it returned the same incorrect hash each time.
it compiles and runs now.
it compiles fine as a c file, just rename sha256.cpp to sha256.c.
it contains the location of the previous transaction's output that it claims and a signature that matches the output's public key.
it contains the public key that the next input must be able to sign with to claim it.
it could always be an android app instead.
it could be it's slow just because you have too many things running at once and you're out of memory.
it could be one pretty formatted string like "0/unconfirmed   0:0:0 date   comment      debit 4  credit 0" or something so it's hard for programmers to do the wrong thing and process it.
it could be the node that you happened to request from is slow.
it could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline.
it could do more volume and probably make more money by processing as many paying transactions as it can.
it could eventually be a valuable revenue stream you wouldn't want to give away to some free site.
it could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites.
it could go either way.
it could take a few minutes to start downloading the blocks.
it could tell if it's not hearing the hum of the world anymore.
it could use a separate (maybe existing) e-mail or im infrastructure to pass messages, and instead of rsa, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message.
it definitely looks like 0.1.3 solved it.
it didn't print any irc activity in debug.log, so i guess it couldn't have gotten past the recvuntil.
it displays "warning: displayed transactions may not be correct!
it displays khash/s in the left section of the status bar.
it does a careful shutdown of everything to be extra safe, in case some important transaction is in progress, but it's completely fine and totally safe to just kill it if it doesn't exit on its own.
it does not change the size of the header.
it does not need to trust a node to verify payments, it can still verify them itself.
it does not slow down your hashing.
it doesn't break the compile for me.
it doesn't care because there's no way to lie to it.
it doesn't delete them on exit, it just leaves them behind.
it doesn't even cause an error, it just doesn't align it.
it doesn't have a bunch of client side scripting or anti-embedding junk to rip out.
it doesn't have to be such a breaking change.
it doesn't hurt anyone, so generate all you want.
it doesn't increase the size by very much.
it doesn't know what transactions or amounts they belong to.
it doesn't look to me like crypto++ could be deciding whether to use sse2 at runtime.
it doesn't matter so much what's embossed on it, just that there be some detail there because it wouldn't look like a coin if it was a blank smooth circle.
it doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
it doesn't receive the blocks, but it didn't run long enough for me to be sure it would have had time yet.
it doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
it doesn't support ssl, but none of them do.
it doesn't.
it downloads in about 30 minutes.
it fails if wxwidgets was built with the wrong configuration.
it felt crowded, the header/logo seemed wrong and the heavy left margin stationery style is outdated.
it generally ranges from 2 to 4 lately.
it generates standard links that work normally.
it gets adjusted every 2016 blocks, typically two weeks.
it gives a warning if you don't set a password.
it gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each os and test everywhere.
it has to be something about the difference on the server besides 64-bit.
it has to read randomly all over blk0001.dat and blkindex.dat to index.
it hasn't been tested on freebsd.
it haven't seen it rebroadcast since 29/09/2010 16:41. you're connecting to yourself.
it helps that it can now seed automatically through tor.
it helps that we have someone with actual experience running a proxy service.
it includes any unrecorded transactions needed to link it back to the timechain.
it includes the fix for the problem nicholas had, checking for disk full and changes to try to improve things that were confusing.
it includes untested changes that are not in svn yet: ui changes and the wallet fspent flag resync stuff.
it is a newborn currency.
it is normal that untranslated strings are shown on top.
it is now uploaded to sourceforge.
it is possible to verify payments without running a full network node.
it is possible, but it's a lot of work, and there are a lot of other higher priority things to work on.
it is relentless though.
it is, but generating is more than twice as slow.
it just needs to be enough for redundancy and fast exponential propagation of messages.
it locks the wallet and copies it, so you can be sure you get a correct copy.
it looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.
it looks good at larger size too, but since the small icons are what you mostly always see, i wanted to judge it on those first.
it looks like a template class to make sure the derived class defines its own version of allocate and deallocate.
it looks like even periodically closing the wallet.dat database to flush it gets the db::close exceptions.
it looks like it has some sse2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available.
it looks like laszlo's build of berkeley db has database/log.
it looks like sockets is somehow partially hosed.
it looks like the implicit conversion from std::string to wxstring isn't working.
it looks like there's a "select failed: 10038" error (the sockets select function failed) and then network communication goes quiet after that (except for irc which is still working).
it looks like we overtook the bad chain somewhere around 74689.
it looks like you were the first one to ever use -datadir with a relative path.
it looks steady to me.
it looks very well presented.
it may be the mac classic support that's complicating wxstring, and we only want osx.
it may have a better chance of working as part of a c program instead of c++.
it may in a little while, since i'm pretty close to making bitcoind build w/o wxbase.
it may not work as expected if you start swapping it around.
it may only need more read caching.
it may take a while to collect re-broadcast transactions.
it may take about an hour to get rebroadcasted.
it may try to match close strings, so check things over and make sure it didn't make any bad guesses.
it might be a long time before we get another donation like that, we should save a lot of it.
it might be the first fully automated service available to buy with bitcoins.
it might help to keep the minimum transaction size above an amount which a typical user would be able to accumulate with one computer, so that users have to trade with each other for someone to collect enough to cash in.
it might just be a really slow connection on the other side, or maybe something's wrong and failed and retried.
it might make sense just to get some in case it catches on.
it might matter.
it might not be good if we suddenly rushed freenode with a ton of users all at once.
it might take longer than we want, since it has to load all the blocks.
it must be a rounding error when getinfo converts to floating point to return the json-rpc result.
it must be blocking the program's network communication.
it must be looking for a larger icon like 20x20 but we don't have one.
it never came up until now because as long as select never failed, receive would never be called unless there was data.
it never really hits a scale ceiling.
it only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while.
it only makes it 0.0000007% slower.
it only makes it compile slightly faster.
it only requires a few changes.
it only starts to apply when a block gets huge.
it only takes one node relaying like it should to cancel out 7 others greedily not relaying.
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.
it ought to have other nodes to try.
it ought to take less than an hour, i think.
it prints "*** restarting threadsockethandler ***" in debug.log, and an error message displays on the status bar for a while.
it prints what it finds in debug.log.
it probably has a sub-0.01 transaction fee in it.
it probably needs the gtk libraries, in which case you'll have the same problem with the 64-bit version.
it probably won't be an actual problem though.
it probably won't be needed, and it can be explained more if we do.
it ramps up the fee requirement as the block fills up: it's a typical pricing mechanism.
it rarely gets used except for announcements like this and major new versions.
it saves us butchering everything with ifdefs and a separate compile and binary to use wxbase just to try to avoid linking gtk.
it says its for masm (microsoft's assembler) and the sample command line they give looks like visual c++.
it seems a node must know about all transactions to be able to verify that.
it seems like 200 would make more sense unless there's something wrong with the mechanics of the http request itself.
it seems like it would be a tremendous hassle to change, and we've had good luck with this one.
it seems like we must in case someone compiles with 64-bit.
it seems like you're inclined to assume everything is wrong more than is actually so.
it seems solid.
it seems to be working.
it sees the network as just a big crowd and doesn't much care who it talks to or who tells it something, as long as at least one of them relays the information being broadcast around the network.
it sets different priorities for each thread.
it should be gavin.
it should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here.
it should be your bitcoin address at home that you received it with.
it should hopefully disconnect all the zombie sockets.
it should not break down the fields into e.g.
it should work.
it shouldn't be hard to update your miner to use it.
it shouldn't be too much longer.
it shows 1.00 but internally it's 1.00000000.  if there's massive deflation in the future, the software could show more decimal places.
it sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.
it sounds like you had exactly the same problem on wine.
it static links libjpeg so that shouldn't be a problem.
it still has to do all the steps.
it still keeps generating as normal, which is necessary for the stability of the network.
it still lets them, it just screws up if they do.
it still needs to receive one valid block to trigger the reorg.
it still seems to me the problem may be one of presenting it the right way.
it still won't let you run two instances at once.
it sure makes website integration a lot easier.
it takes advantage of the nature of information being easy to spread but hard to stifle.
it tells the router which computer handles connections to that port.
it thinks i'm a different s_nakamoto from the one that has admin access: i tried deleting and re-enabling the feature, no help.
it tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected.
it turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
it turns out the solution is to look at button sets instead (http://resources.zetaboards.com/forum/1000328/) i only created two subforums to begin with.
it uses a transactional database called berkeley db.
it uses an algorithm where it tries an ip less and less frequently the longer ago it was successful connected.
it uses the cpuid instruction to get the cpu brand, family, model number and stepping.
it uses the smallest set of coins it can find to add up to near the amount.
it was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time.
it was a difficult choice, because once the network is going it's locked in and we're stuck with it.
it was absolutely the last piece of code to go in and mainly only got tested with the msvc build.
it was almost there.
it was confusing having two address books.
it was getting so there were so many zombie nodes, i was having a hard time getting a reply to any of my messages.
it was in rev 112. the reason i didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure.
it was never intended as a long term feature.
it was only smf where i made some php changes.
it was only there for testing and demonstration of a technical detail that can only be needed in the far away future, if ever, but was necessary to implement at the beginning to make it possible later.
it watches for spent coins and updates your wallet on load and also continuously as blocks come in.
it went for a few hours this time before it did.
it will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in bitcoin's chain.
it will keep nagging the network forever until your transaction gets into a block.
it will not lose data in a system crash.
it will reach an equilibrium where it's not worth it for more nodes to join in.
it won't show generated coins until they have at least one confirmation (one block linked after it), so usually they'll just never be seen.
it won't take very many people running that before we have to make another release just to limit the incoming connections.
it works reliably on linux now, except if it uses wxmessagebox() outside the gui thread, it'll crash because non-gui threads can't open a window on linux.
it works well to secure ownership, but leaves one big problem unsolved: double-spending.
it would be a big plus if it could support ssl, at least for the login page if not sitewide.
it would be a good idea to add a little code that keeps giving the same address to the same ip.
it would be a temporary inconvenience only.
it would be an accident waiting to happen.
it would be awfully annoying to ask each time.
it would be best to refer to the c++ source code.
it would be convenient to buy lr/pecunix with bitcoins rather than through conventional payment methods.
it would be easier for new users to get started if they only need to create an account on a website, not install software.
it would be easy for customers to go bitcoin-just want to save the money, then just bitcoin- there's also the idea btc2psc had to sell paysafecards for bitcoins.
it would be far more work to set up such a site than just to set up a single exchange site of your own, and there won't be enough users to make it go until later.
it would be good to make the download link go directly to the download area: https://sourceforge.net/project/showfiles.php?group_id=244765 i haven't found any way to gain admin control over the mediawiki feature.
it would be great to have at least one other language in the 0.3 release.
it would be hard to split the world down the middle.
it would be instructive to get knightmb's blk*.dat and see if that gets him past that point.
it would be like webmail.
it would be neat if someone had a page (like that handy calculator at ) that projects what the next difficulty adjustment will be.
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.
it would be nice if we made some free php code for an image and file hosting service that charges bitcoins.
it would be nice if when i need to make changes to the homepage, i could enlist someone like xunie to do the rote work of reflecting it to all the translations instead of having to do all that work myself.
it would be nice if you didn't have to re-invent the wheel like you're doing here.
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 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.
it would be nice to keep the blk*.dat files small as long as we can.
it would be nice to know what appears to be the bottleneck when that happens.
it would be preferable if there's any way to do it as a command line switch on the same executable, rather than yet another build variation to release.
it would be sweet if there was some way to horn in on a market like that as the official virtual currency gets clamped down on with limitations.
it would be unwise to have permanently recorded plaintext messages for everyone to see.
it would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
it would be very easy to fumble that up; if you run bitcoin normally to begin with it immediately automatically starts connecting.
it would be very easy to latch onto that for watching for received payments.
it would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee.
it would be weird if that was the actual problem and it made it all the way to release.
it would cost them more in electricity than they'd be selling the bitcoins for.
it would establish a minimum value under bitcoins enabling them to be used for other purposes if, hopefully, other purposes are waiting for something to use.
it would give a normal link directly to the file.
it would have been an explosion of special cases.
it would have said balance 0.01, right?
it would have to be a country deliberately and totally cutting itself off from the rest of the world.
it would have to be your real name for consistency.
it would help if people stop generating.
it would help if there was something for people to use it for.
it would help to condense the article and make it less promotional sounding as soon as possible.
it would help to implement upnp so there would be more inbound accepting nodes.
it would help to know.
it would make it easier for small networks to get started by tapping into a ready base of miners.
it would make sense to actually build one practical application with the api before releasing it.
it would mostly only be reached with generated bitcoins.
it would normally be harmless except in this corner case.
it would not be worth the extra sourcecode bloat.
it would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.
it would only mean finding out you have a generated block 15 minutes later than normal, and then you still have 119 blocks to go before it matures anyway.
it would only take one node to do it.
it would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network.
it would probably be best to default to hide unaccepted blocks, so as not to show giving and taking away something that never was, and not show new generated blocks at all until they have at least one confirmation.
it would probably be possible to initiate an addtoblockindex or reorganize after the check, but it would require a lot more careful attention.
it would still use a different address for each transaction, but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver.
it would tell nodes they don't need to bother to index it.
it would work just like a mailto: link that pops up a new email with the address filled in.
it wouldn't be easy to take advantage of the segmentation to double-spend.
it wouldn't be hard to process orders by hand, especially at first.
it wouldn't have been appropriate for v0.1.0 when stability wasn't a given yet, but now it's good and stable.
it wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.
it wrote the transaction for 10000.20 with a fee of 0.22.  if you look at the transaction on the sender's side, it'll be a debit 10000.42 with transaction fee 0.22.  the bug was that it had to make a rare third pass on calculating the fee, and incorrectly added the first pass' fee to the amount being sent.
it'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now.
it'll be a lot simpler if authors could make their graphics public domain.
it'll be better when the network is larger.
it'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.
it'll be in the next release, version 0.2. command line is on the to-do list after 0.2. bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.
it'll be the only online currency that's both easy to cash out and easy to get a small amount.
it'll detect if the socket hasn't sent or received any data within 60 seconds of connecting, and detect if data is queued to send and hasn't sent for 3 minutes.
it'll get a lot harder when competition makes the automatic adjustment drive up the difficulty.
it'll have to be fixed in the next version.
it'll help if you can accept inbound connections so you'll be listening to more nodes.
it'll help if you port forward so you can get lots of connections.
it'll just be the usual harder difficulty to buy a large amount.
it'll keep giving the same address until something is received on the address, then it allocates a new address.
it'll pop up a message box alerting you if your clock is off by more than an hour.
it'll still try irc first.
it'll tell you that if you run "bitcoind help".
it's a 256-bit unsigned hex number, which the sha-256 value has to be less than to successfully generate a block.
it's a call to openssl that i assumed would never fail, but i put an error check there just in case.
it's a database file, it's not as simple as you think.
it's a feature yet to be implemented.
it's a good idea to keep it lower as a circuit breaker and increase it as needed.
it's a good idea to see how things go with controlling it manually first anyway.
it's a hardcoded block that you start out with.
it's a hashcash style sha-256 proof-of-work (partial pre-image of zero), not a signature.
it's a little like a blog in that case, but easier for users to use it as a searchable faq and better organized.
it's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time.
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's a part of code that doesn't get much use.
it's a perfect example of a service where the needed price point is in the no-man's-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment.
it's a problem when it interfaces with precious metals and currency conversion.
it's a simple json-rpc client and prints the json result.
it's a wxwidgets app, so it doesn't have a main() function.
it's about 100% speedup on amd cpus.
it's about 15 million tx per day for the entire e-commerce load of the internet worldwide.
it's about time we coded in a list of the current long running static nodes to seed from.
it's all prevention.
it's all stl.
it's already an improvement, and like you say, there must be better themes to choose from.
it's also convenient that server farms can run a single bitcoin node and the rest only run getwork clients.
it's always been immediate in the past.
it's an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software.
it's an online currency similar to e-bullion, pecunix or webmoney that allows exchanges no questions asked and with privacy.
it's an open transaction that can be replaced with new versions until the deadline.
it's an sha-256 that takes less than a microsecond, and each guess has an independent chance of success.
it's based on open market competition, and there will probably always be nodes willing to process transactions for free.
it's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and json-rpc available.
it's been getting more difficult at each adjustment since then.
it's been rock solid for me on windows.
it's best if the db does that.
it's best if you don't talk about this transaction fee stuff in public.
it's best if you tell it to me privately so it can be fixed first.
it's coming up in searches as the most widely used protocol and widely supported.
it's completely decentralized with no server or central authority.
it's completely decentralized with no server or trusted parties.
it's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust.
it's currently 29,296 blocks.
it's currently windows only for now.
it's described here: it's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
it's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.
it's disabled by default.
it's easier said than implemented.
it's easier to just static link what we can.
it's easy now but it'll get harder as the network grows.
it's easy to break the hash of short passwords people use on forums.
it's easy to trade bitcoins for other non-repudiable commodities.
it's educational to see what explanations people adopt.
it's encouraging to see more people taking an interest such as that newlibertystandard site.
it's equal cost if you generate the heat with your computer.
it's free open source.
it's fully operational and the network is growing.
it's fully suitable for releases.
it's geared toward image hosting, but i think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting.
it's going to be bdb settings and caching.
it's good to be coding again!
it's good to start low and only have the price go up.
it's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices.
it's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.
it's hard to imagine the internet getting segmented airtight.
it's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.
it's hard to think of how to apply zero-knowledge-proofs in this case.
it's harder to think of how to explain it.
it's header-only so it's no added build work, and small enough to just add it to our source tree.
it's important that two copies of bitcoin not run on the same machine at once because they would be modifying the database at the same time.
it's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.
it's in init.cpp.
it's in recvuntil, but i still can't see anything wrong with it.
it's in the gap between 0 and 19.95.  the best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders.
it's in util.c parsestring.
it's intended that the time is amortised if you were hashing many kb or mb of data.
it's just a matter of getting the time to code it.
it's just an equation that evaluates to true or false.
it's just if you want to be completely stealth that you'd have to go through the -proxy -addnode manual seeding.
it's just status messages that help with debugging.
it's kind of ok if you can't easily read the b in the 16x16.
it's less than 750 words.
it's like generating a new pgp private key, but less cpu intensive because it's ecc.
it's like trying to flip 37 coins at once and have them all come up heads.
it's months before enough changes build up.
it's more of a social networking site, not really conducive to technical discussion.
it's more privacy friendly without it.
it's mostly like what gavin described.
it's mostly only if you were selling gold or currency that you'd need multiple confirmations.
it's much easer to get new users up to speed if they don't have to worry about gpu drivers and compatibility.
it's much too late to change.
it's nice how anyone with just a cpu can compete fairly equally right now.
it's no worse than that.
it's normal and harmless to randomly get some per cent of not-accepted, and of course randomness can sometimes bunch up and look like a pattern.
it's normal and unavoidable.
it's normal for open source projects to have .org so it's not so bad.
it's normal that your cpu meter is 100%.
it's not a big deal if we reach the threshold.
it's not a decision to be taken lightly because once it's done, it doubles my testing and building workload.
it's not a new added dependency.
it's not an exact drop-in replacement.
it's not communicated.
it's not doing anything right now.
it's not enabled yet, but in the svn version it prints a debug message in debug.log showing the new directory value and old value for comparison.
it's not essential and i'm inclined to turn off optimization and delete the section of code until i figure out what's going on.
it's not implemented yet, but the network can support a transaction that requires two signatures.
it's not implemented.
it's not intended to use all or most of the material here, just pick and choose.
it's not like a race where if one car is twice as fast, it'll always win.
it's not like linux where the 64-bit os wants 64-bit programs.
it's not like the incremental step from md5 to sha1.
it's not money sucked out of the system, it just goes to other nodes.
it's not necessary to poll very frequently.
it's not on by default.
it's not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a coin can be identified as being from the owner of that coin.
it's not really crucial to update the translations.
it's not safe to use listtransactions this way.
it's not stable-with-respect-to-energy.
it's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time.
it's not tied to the cost of energy.
it's ok if they come to that conclusion on their own, but we can't pitch it as that.
it's only been 3-4 days since the last increase, so i expect it will increase by the max of 4 times, or very nearly the max.
it's only for viewing the status of your server.
it's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel.
it's only if you generated a block in the bad chain after block 74638 that the 50 btc from that will disappear.
it's only if you use -server or -daemon or bitcoind that it should fail with a warning.
it's only slow to get connected the first time.
it's only tor users that need it, so in the instructions saying "bitcoin -proxy=127.0.0.1:9050 -addnode=<someipsomeip could be an actual static ip, with the wiki free-for-all add-your-ip list nearby or a link to it.
it's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount.
it's possible bitcoin ran and bailed out because something was wrong.
it's possible to be pseudonymous, but you have to be careful.
it's probably some wxwidgets compile defines or build configuration.
it's proportional to cpu speed.
it's relying on 3 time sources: 1) the system clock 2) the other nodes, if within an hour of the system clock if those disagree, then 3) the user (asking the user to fix the system clock) i've thought about ntp, but this is more secure.
it's sent directly when it connects.
it's similar in that it uses digital signatures for coins, but different in the approach to privacy and preventing double-spending.
it's similar to if you encrypt a file with aes and a strong password, and you lose the password.
it's simple enough i could use a generic json parser.
it's slightly wider than tall because the dark perspective under it goes more to the right than down.
it's something wrong deep inside wxwidgets or gtk or gnome.
it's still 1.7x faster from the midstate optimisation.
it's still accepting connections and seems to be alive on irc.
it's still beta software.
it's still very unusual for the public part of sites to be https, probably because it introduces potential technical complications, delays and greater server load.
it's such a standard, more often than not any given project has a projectname.sourceforge.net site.
it's supposed to be only once a minute or 500 blocks: probably should add this: does transaction commit imply flush?
it's supposed to go irc sending: nick after that, and it doesn't so it gets timed out.
it's svn on sourceforge.
it's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.
it's the bug that was fixed in 0.1.3. the communications thread would get blocked, so you would make connections, but they would go silent after a while.
it's the mit license, which just requires some disclaimer text be kept with the source code, other than that you can do just about anything you want with it.
it's the need to check for the absence of double-spends that requires global knowledge of all transactions.
it's the opposite of when a government prints money and the value of existing money goes down.
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.
it's the same situation as gold and gold mining.
it's the total number of blocks in the block chain, meaning the network's block chain, which everyone has a copy of.
it's there for flood control.
it's time we had the same thing for money.
it's too late now for feature changes to 0.3, but i'll add that to the post-0.3 to do list.
it's too much maintenance work to have lots of build variations.
it's trivial compared to the fees many other types of services add automatically.
it's trying to load a translation and failing.
it's trying to tell them their clock is wrong and they need to correct it.
it's unfortunate that we require so many big dependencies, but we need them all.
it's unlikely but maybe possible that the incident could have messed up your block data file.
it's unrelated.
it's while loading the wallet.
it's windows, so i guess ole/com is the interface.
it's worse if you want to upload a file for others to download.
it‚Äôll look like: you can download a pre-release draft at feel free to forward it to anyone else you think would be interested.
i‚Äôll take a look at it and let you know if i have any comments or questions.
i‚Äôm getting ready to release a paper that expands on your ideas into a complete working system.
jgarzik has a cpu miner, and it supports tcatm's 4-way sse2, so on windows it's up to twice as fast as the built-in sha if you have an amd or recent intel (core 3, 5 or 7).
joomla better for cms, drupal better for blogs.
json is tempting and i'm inclined to like it, but two main sticking points: 1) no comments!
json-rpc can be plain socket or http, but it seems most other implementations are http, so i made my own simple http headers.
json-rpc is a simpler more elegant standard.
just a last few things left to do.
just a random streak of bad luck.
just by chance i have my initials.
just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability.
just identifying what it is.
just including the minimum 0.01 goes a long way.
just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good.
just letting you know i'm still working on the linux build so we don't duplicate work.
just money sent to that address, not the whole wallet.
just return "<txid>".
just some random incomplete ideas: there may be a way to position it as an intermediate credit for micropayments for some virtual good or something.
just to confirm, if you log in with the non-latin character username, not having an appdata/bitcoin directory yet, and run bitcoin and let it create the database from scratch, does it work or not?
keeping the threshold lower would help limit the amount of wasted disk space in that event.
key=some full sentence with spaces in it.
knowing what to do with the model number is the hard part.
laszlo corrected this, but unfortunately it was too late to make it into 0.3.0.  there will probably be a 0.3.1 soon though.
laszlo does them, but i haven't asked him to do one for a while because there wasn't anything major.
laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but i assume he used that in his own build.
laszlo told me he did compile in the -4way stuff on mac, so the -4way switch is also available to try on mac.
laszlo's build is going to be our first mac release so please test it!
laszlo's option is a much better fit for us.
later i'll write code to flush the logs after every wallet change so wallet.dat will be standalone safe almost all the time i hate duplicating code, but the compiler forces us.
later i'll write code to flush the logs after every wallet change so wallet.dat will be standalone safe almost all the time.
later visual c versions can't create a standalone exe that doesn't require additional runtime packages installed.
leaves file pointer at end of pchmessagestart.
let it redownload the rest.
let me explain my reluctance.
let me know how it goes.
lets get this into the main sourcecode.
lets go ahead with http basic authentication instead of password as a parameter.
liberty reports that linux-test8 has been running smoothly.
licensewise, it's lgpl, but since it's only used on unix, that would be ok.  (we can't link lgpl stuff on windows because we provide the openssl dll, but on linux openssl comes with the os) my 64-bit (debug stripped) executable is attached.
like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.
like tor says, "tor does not magically encrypt all of your internet activities.
like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.
like you say, there is more software development to be done first, and also i'd like to keep trying for a while to think of a bootstrap application to use bitcoins for.
links removed, 0.3 is now released, so go to to download it.
linux build links below.
linux has a built-in entropy collector.
linux would help server farms, but actually we'd like to favour individual users.
linux-0.1.6-test5 solved liberty's zombie socket problem.
listreceivedbyaddress [minconf=1] [includeempty=false] [minconf] is the minimum number of confirmations before payments are included.
long term, it does keep relentlessly sending it.
look at rpc.cpp for the list of commands.
look for an existing connection connect debug print debug print add node todo: need to set last failed connect time, and increment a failed to connect counter debug print all of a nodes broadcasts and subscriptions are automatically torn down when it goes down, so a node has to stay up to keep its broadcast going.
look right?
looked around at cmses, drupal and joomla are popular.
looks like we've got the fortran scenario already.
looks like your node's com thread just now got blocked on this bug again.
lost coins only make everyone else's coins worth slightly more.
lr and the others are hard to buy but easy to cash out.
lr is non-reversible, so there are oodles of exchanges eager to turn lr into any kind of payment.
lr/pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts.
mac os x didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
mac osx version is available now.
mac support would be nice.
madhatter was working on building it on mac.
main properties: - double-spending is prevented with a peer-to-peer network.
make sure to look through the files in "c:\program files\bitcoin" my fear is too many programmers would latch onto that for checking for received payments.
make sure you read build-unix.txt and configure wxwidgets using the configure parameters given.
make sure you upgrade to bitcoin 0.3.3 as soon as possible.
make sure you use the .po file i uploaded to svn or in a release, because i always fix up at least a few things.
make sure your computer's date and time are correct.
make: *** [obj/sha256.o] error 1 it's too soon to start junking up the api for backward compatibility at all costs.
makefile.unix: - 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.
making bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution.
manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.
many businesses are like that.
many complex concepts in the world have a simplistic explanation that satisfies 80% of people, and a complete explanation that satisfies the other 20% who see the flaws in the simplistic explanation.
many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another.
many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things.
many small flats have electric heat out of convenience.
many such sites have a free trial anyway.
many switches are intentionally undocumented, like if their functionality is still under construction or i haven't settled on their name yet, or just test code not intended for release.
mark old coins as spent broadcast this must not fail.
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.
martti and i have been working on a new version to release soon and it would be nice to get any wine fixes in there.
martti originally had it separate and i made it a sub-option, my bad.
martti should give you the drupal admin password.
martti's linux port was merged into the main code branch and new liberty standard has been testing it.
martti, how long did it take to start downloading blocks when you ran it, and how fast did it download?
maybe "*" special case like "" is.
maybe a better more immediate solution is to connect through tor, which will be possible with 0.2. that's one of the main things on the agenda after 0.2. yeah, the other stealth stuff would be kinda pointless if it's always the same port number.
maybe berkeley db has some tweaks we can make to enable or increase cache memory.
maybe call bitcoin, get work from it, hand it to bitdns getwork to combine into a combined work.
maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers.
maybe due to the site reorg they just did.
maybe i'm not looking in the right place.
maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange.
maybe it forgot.
maybe it has a setting for how much cache memory to use.
maybe it should always return 200.  i think someone sounded like the 500 might be causing a problem.
maybe it should be 10. since nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium.
maybe it should have been built on an older version for more backward compatibility.
maybe it's just me, but i really like the random blue squares.
maybe on gtk it scales it for you.
maybe pitched like help support the future of e-commerce and get a little money for your computer's spare cycles.
maybe some bit of init code it tries to optimize out if it's not called at least once in the same thread, or some stl optimization that's not thread friendly.
maybe some malfunction from the lack of gui.
maybe some of you are responding to other posters who suggested the alert system should do more?
maybe someone with more linux experience knows how to install the library it needs.
maybe sourceforge was doing some maintenance.
maybe that will be in cold climates where there's electric heat, where it would be essentially free.
maybe the current difficulty of buying lr is already the limit of how easy it can get in that direction.
maybe the data transfer could be done as an e-mail attachment.
maybe there are other versions of it to try.
maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
maybe there's some magic flag or procedure to bash the sockets system back to life.
maybe there's something wrong in it.
maybe think of it as a reference coin that you measure other coins against.
maybe this is just something about linux that it takes a minute to free up a port you had bound.
maybe we should do this: again, those paths help make sure it's only 2.9 and will fail with 2.8. wxwidgets 2.8 comes in ansi and utf-16, both wrong for us.
maybe we should look at where some other projects have their forums hosted for ideas where to look.
maybe we should statically link the gtk.
maybe you could create the website on sourceforge, which is currently blank.
maybe you should have a minimum time between payments per class-b.
maybe you were just unlucky to have an exit node without reverse lookup.
maybe you're the first person to ever run it on vista i have to guess it has something to do with your display color depth selection.
maybe: any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software.
merchants must be wary of their customers, hassling them for more information than they would otherwise need.
merchants would get too many blank payments followed by "i paid you, where's my stuff?!"
message header (4) message start (12) command (4) size the message start string is designed to be unlikely to occur in normal data.
messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
messages should not be recorded in the block chain.
micropayments are almost always for intellectual property, where there's no physical loss to the merchant.
microsoft changing the directory name with every windows release and being full of spaces and so long it runs off the screen.
microsoft security essentials live protection is blocking your communication with the network.
midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing.
might also make the initial block download faster.
might have privacy or denial of there's at least one node who's inbound ip keeps changing all the implemented, there's plenty of time now to fully think through the design and make sure it's the best way.
might take 1 minute.
mihalism multi host is a popular open source php file hosting server.
mind if i add you to the project developers list on the contact page?
mind what's behind it for the transparent parts.
miner writers better make sure they never false-positive near-hits.
miners would subscribe to both networks in parallel.
mingw is gcc 3.4.5.  probably the problem.
mingw on windows has trouble compiling it: please submit a full bug report, with preprocessed source if appropriate.
mingw still only has good old stable 3.4.5.  there's not much reason for them to update it.
mingwm10.dll is a tiny little dll that came with the mingw compiler that you need when you build for multi-thread.
mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.
misc bugfixes in rev 130: fix -datadir with relative path autostart is now off by default except on windows fix occasional "vector iterator not dereferencable" assertion when compiled with msvc fix readlink compile warning on linux build use sys/param.h and bsd define instead of __bsd__ -paytxfee switch, e.g.
mit license.
more directly, this: i will be posting release candidate of 0.3.1 with this fix shortly.
more generally, we could also consider this: we would then rely on dbenv.txn_checkpoint(0, 0, 0) in cdb::close() to flush after wallet writes.
more impressive looking.
more interesting is the zombie sockets activity towards the end, and the socket thread monitor tripped but didn't get it going again.
more like a collectible or commodity.
more likely it would be a single country vs the rest of the world, lets say a 1:10 split.
moreover, the„Ç‚†router's ip should also be checked to avoid a single user broadcasting„Ç‚†an insane number of transactions„Ç‚†(fees may apply in this situation).
moreso with hyperthreading enabled.
most customers who convert to lr to buy something would probably ask the seller first if they accept bitcoin, encouraging them to start accepting it.
most forums run vbulletin (big-boards.com lists 1376 vbulletin, 275 invision, 245 phpbb and 41 smf), so if you don't look like vbulletin or invision, it looks like you compromised because you couldn't afford vbulletin.
most instant-access products aren't going to have a huge incentive to steal.
most new programs like firefox store their settings files there, despite the headwind of microsoft changing the directory name with every windows release and being full of spaces and so long it runs off the screen.
most new programs like just now added code to the next release for that.
most of the fixes are on the sender's side, so if you were downloading the network upgrades to 0.2. how long did the initial download take?
most of the value comes from the value that others place in it.
most of wxwidgets is not thread-safe to use in threads other than the ui thread, but as a rule of thumb on windows anything not ui related is ok. it turns out its more thread-unsafe on gtk.
most people are already familiar with the interface.
most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.
most sites selling digital goods are fine to accept 0 confirmations.
most sites that sell things will need something like this.
most users don't have a static ip, and it's too much trouble to set up port forwarding.
mostly only devs and people checking on a bug need read the technical support section.
moved the "your addresses" book inside the main address book.
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.
moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00. when you send to a bitcoin address, you don't connect to the recipient.
msg_dontwait in test5 solved the zombie problem for liberty.
much more of the work was designing than coding.
multiple people on the forum have expressed interest in tor/i2p, and those users need ssl because a lot of tor exit nodes are probably password scrapers run by identity thieves.
my apologies, your post was indeed a question not a statement.
my back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way.
my choice for the number of coins and distribution schedule was an educated guess.
my description of how bitcoin solves the byzantine generals' problem: oh crap, i got your sourceforge usernames mixed up, sorry about that.
my first experiment was to try something besides yet another blue site.
my head hurts just thinking about that.
my last svn commit included an overhaul of the code that selects the order of addresses to connect to, trying them in the order of most recently seen online, so it should get connected in a more reasonable amount of time if irc is unavailable.
my priority right now is to get a forum going, either phpbb or similar.
my testing has been with msvc 6.0 sp6 and gcc 3.4.5. gcc is the release build.
my tests have been running fine as well.
my writing is not that great, i'm a much better coder.
name change.
nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it.
neat chart.
network speed and storage space should be able to increase in the future so that big block is possible for all the clients(even for mobile clients) in time.
network support will be thorough there'll be enough clients who understand how to receive and interpret the new transaction.
never heard of that happening.
new demonstration cpu miner available: despite everything else said, the current next step is: in particular, i suspect that more read caching might help a lot.
new features: - gavin andresen's http authentication to secure json-rpc - 5x faster initial block download, under 30 minutes the json-rpc http authentication feature in 0.3.3 solves this problem.
new icons, what do you think?
new nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without pow.
new or renamed functions are: amount received on a single address amount received by all addresses with this label list addresses and amounts they've received list labels and amounts they've received misc label functions for completeness for consistency i renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress.
new transaction broadcasts do not necessarily need to reach all nodes.
new transaction templates can be added as needed.
new users wouldn't really even need the bitcoin software.
next time i update to the latest versions, maybe i'll lay everything out in one directory tree and bundle the whole thing up into a giant archive.
nice graph!
nid_secp256k1 is a constant.
nls's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.
no challenges or secret shares.
no help from -o0, same error.
no, don't "bring it on".
no, each generated transaction uses a new, single-use address.
no, not at all.
no, not related at all.
no, sorry.
no, the other nodes won't accept that.
no, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.
no, they can't make money that way.
nobody has to ever actually claim the lr to get the benefit of having the option that they could if they wanted to.
nobody is going to be able to make a living off stealing access to websites or downloads.
nodes always consider the longest chain to be the correct one and will keep working on extending it.
nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them.
nodes can do two things in response to an alert: - put a warning message on the status bar.
nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone.
nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.
nodes only take so many kb of free transactions per block before they start requiring at least 0.01 transaction fee.
nodes stop trying to initiate connections once they have 15.  if you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15. i don't know if there's any reason to have 15 connections.
nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.
nodes will only work on adding those transactions to their block.
nodes work all at once with little coordination.
nope.
normally i would keep the symbols in, but they increased the size of the exe from 6.5mb to 50mb so i just couldn't justify not stripping them.
normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
normally when it does that it's because the directory where the data directory should go doesn't exist.
not all sites need to wait for confirmations, so the dual current & available should be optional.
not completely filled up with stuff, just a few things.
not everyone has 0.3.13 yet.
not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  the dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
not locktime.
not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
not only single-threaded, but must-be-the-gui-thread-ed.
not opening any windows is easy, but it may fail because the gtk libraries aren't there.
not really.
not saying it can't work without something, but a ready specific transaction need that it fills would increase the certainty of success.
not sure what it should be named.
note that the chains are below this new merkle tree.
note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2. download: (thanks laszlo for the mac osx build!)
note: the sse2 auto-detect in the linux 64-bit version doesn't work with amd in 64-bit mode.
note: there's a bug with tray icons sometimes disappearing on 64-bit karmic koala, not sure if it's from 64-bit or karmic, it was fine on 32-bit jaunty.
notes: - it does not return work when you submit a possible hit, only when called without parameter.
nothing against gpl per-se, but bitcoin is an mit license project.
nothing uses the address in the main window, it's just there for convenience for you to copy.
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.
now that i think about it, when you close bitcoin, it closes the main window immediately but in the background continues running to finish an orderly flush and shutdown of the database.
now that i think about it, you've put your finger on the most important missing feature right now that would make an order of magnitude difference in the number of nodes.
now that it's clear this is a key error message, it ought to be something more like "the money appears to be already spent...  this could happen if you used a copy of your wallet file on another computer."
now that the forum on bitcoin.sourceforge.net is catching on, we really should look for somewhere that freehosts full blown forum software.
now that we have the accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.
now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and i'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely.
now, four inventory messages go out, four getdata messages come back.
ntimelock does the reverse.
obviously sha256 should be slower than sha1 by a certain amount, but not by as much as i saw.
occasionally a generated coin that was displayed might disappear because it became not accepted later.
of communication i group attacks into two classes: 1) attacks that can only be done by someone actually in the chain local lan, admins at isps in between, and the lan on the 2) attacks that can be done by anyone on the internet from anywhere type 1 exposes you to people in your house or company on your develop one technique to attack multiple victims.
of course, the biggest difference is the lack of a central server.
of the nodes i'm connected to, more than half are already 0.3.10.  i would say we probably already have more power than the bad chain.
off topic, but: it would be nice if someone would hack on getting tcatm's 4-way 128-bit sse2 code working on windows.
offering currency to back bitcoins would attract freebie seekers, with the benefit of attracting a lot of publicity.
often the standard answer about legalities is that it's only intended for people in other countries.
oh great, now we're screwed.
oh i see, you're trying to address byronm's concern on freedomainradio.
oh well.
oh, do you mean send a different variation to each node with the tx fee written to them?
ok, back to 0.3 then.
ok, i changed the password to a 20 character random password.
ok, i made a build target bitcoind that only links wxbase and does not link gtk.
ok, if it really won't get past block 1698 on redownload, then we're in stranger territory.
ok, maybe now i see, if that's it.
ok, thanks.
ok, the undocumented switch "-minimizetotray" which re-enables the option.
ok, this must be a problem somewhere, i'll have to take a look at it or one of the other devs can.
old blocks can then be compacted by stubbing off branches of the tree.
old transactions can change at any time.
older is better.
older version senders will get "transfer was not accepted".
on 30 dec we broke above it and the algorithm adjusted to more difficulty.
on an intel core 2 duo t7300 running x86_64 linux it was 55% slower compared to the stock version (r121) my core2quad (q6600) slowed down 50%, my i5 improved ~200%, on an amd opteron 2374 he running x86_64 linux i got a 105% improvement (!)
on both mingw gcc 4.4.1 and 4.5.0 i have it working with test.cpp but sigsegv when called by bitcoinminer.
on gavin's idea about an existing p2p broadcast infrastructure, i doubt one exists.
on karmic they only have the utf-16 version.
on linux i assume the codepage is already utf-8.
on linux it needs libgtk2.0-0 installed, but does not need a gui running.
on linux we'll never close a database handle until we're ready to exit.
on linux, it also looks for: /usr/share/locale/<langcode>/lc_messages/bitcoin.mo /usr/local/share/locale/<langcode>/lc_messages/bitcoin.mo (are there other standard places it should look on linux?)
on the op's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time?
on the stats at there's been 5 blocks per hour in the last 3 hours.
on ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so i made it leave it there.
on windows at least, it creates six __db.001 - __db.006 files with sizes from 24k to 4mb.
on windows it's seeded with the complete set of all hardware performance counters since your computer started, on linux it's dev/random.
on windows, findstr /c:"version message" debug.log it looks like the bad chain was on block 74678 recently.
on windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc.
on windows, the .mo files would go in a lang subdirectory in the directory where the exe is located.
on windows, the option adds/removes an icon in the startup folder.
on windows, use: findstr "hashmeter generated" "%appdata%\bitcoin\debug.log" i have the hashmeter messages once an hour.
on windows, we set the codepage to utf-8, so on all platforms our code is utf-8 and wxwidgets interfaces with us in utf-8.
on wxwidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash character, which this hack fixes up for the non-unicode (ansi) case.
once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.
once it gets bootstrapped, there are so many backup.
once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old.
once it's backed with cash, that might change, but i'd probably better refrain from mentioning that in public anymore until we're closer to ready to start.
once that is established and proven out, dynamic smart money is an easy next step.
once the cpu effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work.
once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.
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.
once the software support is implemented, anyone could contribute translations.
once the status is above 5 or so it's safely accepted.
once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.
once we password encrypt the wallet, we'll be able to make a clearer case that we're much more secure than banks.
once you get away from a system where each node's influence is proportional to their cpu power, then what else do you use to determine who is (approximately) one person?
once you get seeded, you don't need irc.
once you have an update, you could download knightmb's block chain.
once you know there's a flood, you can add -paytxfee=0.01.
one alternative is to use a round-up system.
one easy thing that really helps is to run a node that can accept incoming connections (forward port 8333 on your firewall) to make sure that new users who try it out have someone to connect to.
one good one i found was mihalism multi host.
one line of text per thread, small fonts, efficient use of vertical space.
one more factor that would mitigate spam if pow tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest pow tokens from spam.
one of the fundamental building blocks for such a system is digital signatures.
one of them, wxmac, exists in two versions: classic and carbon.
one problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-utf-8 ) of wxwidgets that happens to be there.
one solution would be to use both the ip and bitcoin addresses system starts to be used for real business purposes, i will the public key of the bitcoin address to sign the new public key to prove that you're sending to who you think you are.
one strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.
one thing that's needed is an interface for server side scripting languages such as java, python, php, asp, etc.
one thing we could do is lower the outbound connections from 15 to 10 or maybe even 5.  the choice of 15 was arbitrary.
only a few specific people will do any website design work and those people can go ahead and have a separate login.
only digital signatures.
only in the 1500 khash/s range.
only one size is provided.
only that key can control it.
only the -4way code is compiled this way.
only the buyer signs, and there's no blinding.
open bitcoin.po with poedit, do catalog->update from sources.
open history file overwrite with empty null block describes a place in the timechain to another node such that if the other node doesn't have the same branch, it can find a recent common trunk.
open it with poedit and do catalog->update from sources.
open source c++ code is included.
openoffice is another example of something that puts its link in the startup folder.
openssl automatically uses /dev/urandom to seed on linux, so randaddseedperfmon can also be a no-op.
openssl doesn't have any interface for doing just the low level raw block hash part of sha256.
openssl is the harder one to build.
or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
or if we could get someone to set one up.
or if you don't want to mess with downloading blk files, you can just do this: 1) shut down.
or managing how much priority you spend on a transaction.
or maybe if the payments are only in one direction.
or maybe just a "new address" button next to the address box that you should hit each time to change it.
or read the forum to find out more.
or some ip seed addresses posted on a wiki page with the instructions.
or what about an http interface on some port other than 80 to manage it with a browser?
or you could pay per day.
or you could run it in gdb and step through threadircseed or u to step over and up out of routines.
or, they could always accept old transactions, but only a limited number per time period.
originally, a coin can be just a chain of signatures.
other compilers might have different 64-bit defines.
other nodes must receive it and link to it for it to be accepted as the new latest block.
other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.
other than the version number change, which included changes in readme.txt and setup.nsi, i reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections.
others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key.
otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating.
otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.
otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections.
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.
our hack to ignore the initialize failure and run anyway means we're in uncharted territory.
out of memory maybe.
paid to receive spam.
parameter is not working because its changes are rejected because apache is not configured with "allowoverride all".
past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.
patch is uploaded to svn rev 132!
payment up front: customer loses, and the thief gets the money.
payments by bitcoin address are broadcast over the network as part of the normal network traffic.
pdb->get, pdb->put, pdb->del compiled before that.
people automatically react violently against any suggestion of a spam solution.]
people had endless build problems with 2.8 and its wxstring utf-16/ansi conditional build options until we standardized on 2.9.  also, to use 2.8, we were using ansi, which was just a temporary stopgap until wxwidgets supported utf-8.
people have told me they find it annoying to have to look at them, as they're permanently displayed in the transaction record.
people only need one hash to make sure that the entire blockchain is genuine.
people rarely type domain names anymore, they use autocomplete or click links on search engines.
people will see that they can't just get all the bitcoins they want.
people would obviously be sceptical at first that the backing will hold up against an onslaught of people trying to get the free money, but as the competition raises the proof-of-work difficulty, it should become clear that bitcoins stay scarce.
per 1000 or per day may be easier for consumers to get their heads around too.
perhaps there's a way for someone to manage the updating of the translated drupal pages.
perhaps this is intentional to keep tor so it can't be integrated into file sharing programs in any sufficiently automated way.
php includes it in its standard libraries.
php, java, python or anything will be able to talk to the server directly the same way the command line commands do.
php, python and java all have good implementations of json-rpc.
piling every proof-of-work quorum system in the world into one dataset doesn't scale.
place your .po file 3 directories deep under the src directory.
please check that this is fixed for you.
please don't try ppc.
please download rc4 and check it over as soon as possible.
please go ahead and post it (and relieve the suspense for everyone!)
please keep running v0.3 if at all possible, don't go back to v0.2.10.
please report back your cpu and results!
please test 0.3.2.5 in preparation for the 0.3.3 release!
please try that and let me know if it fixes the problem.
please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency: let me know if that works.
please try this instead and let me know if it gets it right: you can still control the sse2 use manually with -4way and -4way=0.
please upgrade to 0.3.6 asap to get an important bugfix.
please upgrade to 0.3.6 asap!
plus, we'll include the german, dutch and italian translations by datawraith, xunie and joozero (thanks you guys!).
pm or e-mail me your sourceforge account and i'll give you access.
poedit does it.
poedit reorganised the file for some reason.
pool operators can modify their getwork to take one additional parameter, the address to send your share to.
port 8333 on your firewall needs to be open to receive incoming connections.
port forwarding forwards a port to one computer.
possibly a security feature so some trojan doesn't kill the web server and quickly jump into its place and pick up all the client retries.
post if you figure out what wrong.
post if you generate a block with this.
ppc is big-endian and bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there.
ppc is on its way out anyway.
pprev and pnext link a path through the main/longest chain.
pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.
predicate is a long and unfamiliar word so i called it script.
priority doesn't have to do everything.
priority is a more formalised version of the concept you're describing.
priority is sum(valuein * age) / txsize.
privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors.
probably a false alarm.
probably about time i did it now.
probably best to disable receiving by ip unless you specifically intend to use it.
probably functions unimplemented by wine that are harmlessly stubbed out.
probably need to sign the order info so know it came from payer would be nice for it to return the version number it reads, maybe use a reference nodes collect new transactions into a block, hash them into a hash tree, and scan through nonce values to make the block's hash satisfy proof-of-work requirements.
probably not an issue anymore, but might be a good idea to delete or update that wiki page.
probably ok, but i'm not sure.
probably releasing shortly.
probably should post a question on the forum or the mailing list and see if anyone knows one.
problem is, i think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for.
program shortcuts have multiple tabs of settings with lots of little details.
programmatic api used by php (any language) to present a web ui covers remote admin, mobile and any other client that can't be online all the time with a static ip.
programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since i last asked, and i'll keep my own tally or static record of them.
proof-of-work has the nice property that it can be relayed through untrusted middlemen.
proof-of-work is essentially one-cpu-one-vote.
propagating a transaction across the whole network twice would consume a total of us$ 0.02 of bandwidth at today's prices.
question is whether that would be more output than the user wants when they grep.
random unidentified payments volunteered to the server's ip address would be unhelpful.
range - switch -maxconnections=# i added the (currently undocumented) switch -maxconnections=#.
rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.
read build-unix.txt and use the given ../configure parameters on wxwidgets so you can use the makefile.unix.wx2.9 as supplied.
read caching would help that.
really?
receivers of transactions must wait a few blocks to make sure that resolution has had time to complete.
receiving payments is the part that has a lot of design choices to be made.
recent changes: build-unix.txt: - added instructions for building wxbase, which is needed to compile bitcoind.
recipient's side.
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.
red, thanks for telling me privately first!
refer to the win32 documentation for setthreadpriority() for more information on win32 priority issues.
regular users aren't used to the idea of having to identify the payment.
relay paying transactions to me, or i won't relay them to you.
release build, or built it yourself?
removing -d__wxdebug__ from bitcoin's makefile would probably solve it.
removing the limit will remove its final barrier.
rename to .tar.bz2 or just do tar -jxvf what was the reason for this change?
renewal.
repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a bitcoin payment mechanism.
returns an array of objects containing: "address" : receiving address "label" : the label of the receiving address "amount" : total amount received by the address "confirmations" : number of confirmations of the most recent transaction included or listreceivedbylabel if you're labelling addresses with their username.
reverted makefile.unix.
ribuck's description is spot on.
right away, slowly over a long time, or starting at some later event?
right now (04:50 gmt) my node is connecting to yours and getting zombie connections each time.
right now i'm working on json-rpc and command line support, but when i'm finished with that i hope to do this next.
right now there are a lot of people on the network who can't receive incoming connections, so every node that can really helps.
right now there isn't a port number setting to do that.
right now, such a node would get nothing, because nobody includes a fee, but if enough nodes did that, then users would get faster acceptance if they include a fee, or slower if they don't.
right, i'll change it to this so it doesn't get broken again: the json-rpc implementation is going well.
right, if it's equal in length, ties are broken by keeping the earliest one received.
right, that is quite a bit better.
right, the credit field stays 0.00 until it matures, then it'll be 50.00.  btw, you can doubleclick on a line for details.
right, the credit field stays 0.00 until it matures, then it'll be 50.00.  do you think it would be clearer if i left the credit field blank until it matures?
right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour.
right, the exchange rate between domains and bitcoins would float.
right, the svn has the almost-release-candidate 0.2 source, which can also be built and run on linux.
right, they'll re-appear when it's finished downloading all the blocks.
right.
rpc backupwallet <destination> is in svn rev 147. thanks.
rsa can do both, but i didn't use it because it's an order of magnitude bigger and would have been impractical.
rsa can encrypt messages, but it's many times bigger than ecdsa.
rsa vs ecdsa: it's not the size of the executable but the size of the data.
run it with the undocumented switch -minimizetotray and the option is available in the options menu.
safe mode can still be triggered by seeing a longer (greater total pow) invalid block chain.
same amount of money, just different convention for where the ","'s and ".
same if a block didn't have enough proof-of-work.
same with the recipient.
says 212 blocks in the last 24 hours, or 8.8 per hour.
scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
scanhash_ functions aren't going away.
scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).
search "bitcoin" on google and see if you can find more big references in addition to the infoworld and slashdot ones.
search debug.log for "proof-of-work found".
search on cpuid.
search on getnewaddress and you should find a thread where i gave a small fragment of sample pseudocode.
searching for themes is futile, there are thousands of rubbish themes.
searching the comments text for an order number is another possibility.
section 11 calculates the worst case under attack.
section 9, combining and splitting value.
see <url:http://www.mingw.org/bugs.shtml> for instructions.
see bitcoin.org or the sourceforge link.
see cdb.
see if the "%appdata%" directory exists.
see the snack machine thread, i outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less.
see this thread: download: another option is to reduce the number of free transactions allowed per block before transaction fees are required.
see: i agree.
seeing the unaccepted blocks is just annoying and frustrating.
seems do-able even with today's technology.
seems like i too often hit limitations.
seems overkill.
seems they changed everything around in boost recently, "-mt" and all that, makes it hard.
senders with this version will get the error "recipient is not accepting transactions sent by ip address".
sendfrom(username, bitcoinaddress, amount, 6) i have the beginning of something like this.
sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network.
sending by bitcoin address has a number of problems, but it's so nice having the fallback option to be able to send to anyone whether they're online or not.
sending to a bitcoin address doesn't have that problem.
separate machines are automatically collision proof because they have different generated public keys in the first transaction.
seriously?
service issues.
services like this would be great for anonymous users, who have trouble paying for things.
set it to belownormal or low.
set version on stream for writing back same version basic checks that don't depend on any context check for negative values read transaction return file pointer a transaction with a merkle branch linking it to the timechain a transaction with a bunch of additional info that only the owner cares about.
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.
sha-256 is a 32-bit algorithm and nothing in bitcoinminer uses 64-bit at all.
sha-256 is very strong.
sha256 begins by wrapping your data in a specially formatted buffer.
sha256 is not going to be broken by moore's law computational improvements in our lifetimes.
sha256 is not like the step from 128 bit to 160 bit.
sha256 was a lot slower than the fastest sha1 at the time than i thought it should be.
shadowofharbringer, is yours faster with -4way?
sheriffwoody: bitcoin addresses you generate are kept forever.
should have some fee that goes to the miners.
should they be able to explicitly disable the password requirement?
should we enable sse2 in all the makefiles?
should we go ahead with that?
shouldn't be too hard to debug with gdb.
sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case?
silently failing would look bad.
simple escrow: customer loses, but the thief doesn't get the money either.
simplified payment verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network.
since 2007.  at some point i became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it.
since all or most of the neighbours should eventually have each item, even if the coms get fumbled up with one, they can get it from any of the others, trying one at a time.
since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
since bitcoin can't get through to irc through tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes.
since it's authenticated, it would then be safe to allow the ip address to be a domain name.
since it's idle priority, it won't actually slow anything else down, even though the cpu meter is 100%.
since the effective circulation is reduced, all the remaining coins are worth slightly more.
since there's no ssl login, i want to mainly use that account with sub-admin powers and use the admin account as little as possible.
since we're upgrading to wxwidgets 2.9.0 for utf-8, which doesn't have a deb package yet, we'll continue to need to static link it.
since you've been connected before, your addr.dat contains known node addresses, but without irc to know which ones are online, it takes a long time to find them.
since your blocks were not broadcast to the network immediately, the network went on without them.
since your computer started.
sirarthur has a good point about the normal online merchant case, which is what the send-by-ip option is more suited to.
sirius-m: thousands of own addresses should not be any problem at all.
slower machines produce fewer coins.
small enough to include what you might call the top of the micropayment range.
small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth.
smf has code that changes all the links to https if the url handed in is https.
smf's ui started out further away from the standard look, but i've been able to use css to make it look more like the others.
so dang, there goes all the nice wxwidgets portability support functions.
so far i've been putting it off in favour of other features because it's not crucial yet until bitcoins start to have value.
so far i've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet.
so far in this discussion there's already a lot of housekeeping data required.
so far with this disabled, no exceptions.
so for example, you have: thanks eurekafag, russian translation added to svn rev 160. make sure you keep your node online so it'll keep rebroadcasting transaction b412a0.
so i guess this is why.
so if i do some testing later i don't have to figure it out myself.
so much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.
so now it doesn't look like it's the version of gcc, it's something else, maybe just the luck of how the stack is aligned.
so that was responsible for keeping blocks from downloading?
so that's the computer receiving.
so the limit can be removed.
some care taken that if a proxy is used, it uses socks4a instead of dns lookup.
some i can think of: ssl get away from sourceforge's unreliable hosting everything not logged by sourceforge the forum feature is about as weak as bitweaver.
some issues that we don't have easy answers for are best not to bring up.
some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.
some more rpc interface: move <fromaccount> <toaccount> <amount> move from one internal account to another.
some numbers?
some of their responses were rather neanderthal, although i guess they're so used to being anti-fiat-money that anything short of gold isn't good enough.
some of them give little attention to the windows build.
some places where generation will gravitate to: 1) places where it's cheapest or free 2) people who want to help for idealogical reasons 3) people who want to get some coins without the inconvenience of doing a transaction to buy them there are legitimate places where it's free.
some posters complain all the c++ and php xml-rpc libraries are buggy.
some sample pseudocode using the new accounts based commands in 0.3.18.
some things based on questions and feedback i've received that'll reduce confusion.
some transactions: changing the ip record.
some virtual currencies like tencent's q coin have made headway with virtual goods.
someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back.
someone bought out all he had.
someone came up with the word "cryptocurrency"... maybe it's a word we should use when describing bitcoin, do you like it?
someone handling a lot of money still gets to see a lot of transaction history.
someone has been paying a 0.00000010 transaction fee.
someone reported that it works fine in wine.
someone says you might also have to the error in the error log is: failed to open stream: permission denied (i'm sure that's just the first file) is it ok to go live with this smf installation when i'm finished configuring it?
someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend.
someone should confirm if they followed it and didn't run into any snags.
someone should experiment with different berkeley db settings and see if there's something that makes the download substantially faster.
someone should periodically irc to the bitcoin channel on chat.freenode.net and count the number of users.
someone should post their static ip so people can try out sending by ip and also give that user free money.
someone should write this up in a pegged thread.
someone trying to brute force would have to take time generating a key for each attempt.
someone who's kept up on the json-rpc threads here should have some idea how it should work.
someone with lots of compute power could make more money by generating than by trying to steal.
something in sending personal messages also uses captcha.
something that's allowed in url parameters would be nice.
something to get new users up to speed on what bitcoin is and how to use it and why, and clean and professional looking would help make it look well established.
sorry about that.
sorry to be a wet blanket.
sorry, actually it's ecdsa (elliptic curve digital signature algorithm) not rsa.
sorry, i didn't test compile on linux the last few revisions.
sorry, i linked to wxbase but i had full wxwidgets on my computer.
sorry, i've been so busy lately i've been skimming messages and i still can't keep up.
sorry, not yet, but i do want to make the initial block download faster.
sounds like an obscure enough candidate.
sourceforge has a policy of not allowing removal of files once they're added, and it's a pain to upload to.
sourceforge is just so darn slow.
sourceforge is so slow right now i can't even get the login page to load.
spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field.
special thanks to nicholas and dustin for all their help and feedback!
spend what you need on hosting.
spv is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.
sse2 has been around since the first pentium 4.  a pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.
starting at 67000 is yeah, at the moment you'll stop at 74638.  it should start slowly creeping up as more nodes upgrade and generate.
static const int64 transactionfee = 1 * cent; /change this to a user options setting, optional fee can be zero static const unsigned int minproofofwork = 40; /need to decide the right difficulty to start with static const unsigned int minproofofwork = 20;  /ridiculously easy for testing an input of a transaction.
status of my research currently: for php, python, etc to access the server, we need to use regular sockets.
steps: 1) copy the current bitcoin.org index.html to the new server exactly as-is.
still gotta figure out how to do the xpm version of the icon correctly.
still thinking this idea through... the only job the network needs to do is to tell whether a spend of an outpoint is the first or not.
still, the system won't be entirely secure against your blk*.dat files.
strange that intel has 3 128bit units, but amd with 2 128bit units is the faster one.
strings aren't added or changed very often.
stuff that requires admin can't start on startup on vista.
subscribe our local subscription list wait poll the connected nodes for messages receive messages send messages wait and allow messages to bunch up todo: start one thread per processor, use getenv("number_of_processors") sockets startup get local host ip create socket for listening for incoming connections set to nonblocking, incomming connections will also inherit this the sockaddr_in structure specifies the address family, ip address, and port for the socket that is being bound listen for incoming connections start threads sockets shutdown   there's more work to do on dos, but i'm doing a quick build of what i have so far in case it's needed, before venturing into more complex ideas.
subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.
such is the challenge of making icons.
suggestions?
suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven.
suppose both spends are to the same address.
sure feels like it could be something in wxwidgets retrying endlessly because some ui thing failed or something wasn't inited correctly.
svn rev 111 that's strange, didn't someone just say that was supposed to work?
svn rev 125: - always make 8 outbound connections even if have 8 inbound - limit outbound connections to one per a.b.?.?
svn rev 128: disable sse2 on 32-bit.
svn rev 139 does a basic check of the block chain after loading.
svn rev 141 pops up a message box if your clock is too far off.
svn rev 145. this stuff is very new and may still be subject to change.
svn rev 150 has some code to try to auto-detect whether to use 4-way sse2.
svn rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent.
sweet, i was looking for a group like that on usenet at one point to see what i would use if i needed, and nothing really fit.
taking too long could confuse other users.
target is little endian, it's supposed to be the same as how m0mchil's did it.
tcatm's 4-way sse2 sha-256 is in the file sha256.cpp and already uploaded a few revs ago.
tcatm's sse2 code must be a mix of normal x86 instructions and sse2 instructions, so while one is doing x86 code, the other can do sse2.
tcatm, try amdfam10 and make sure you get the same speed measurement.
technical support makes sense as a separate section to get that stuff out of the main spotlight so our dirty laundry isn't in everyone's face, and to make people feel more free to report bugs there.
technically, yes, the genesis block is a block.
temporarily let more spam through, it would only hasten the in the first place, since spammers that don't have a botnet could buy tokens from harvesters.
test3: i've added specific code to detect zombie sockets.
testing at this point is much appreciated.
tests on windows private lan download of 78500 blocks: with db_private     20 minutes 51 seconds without db_private   20 minutes 51 seconds i wasn't expecting them to come out exactly the same.
thank you for limiting flood tests to the testnet.
thank you for the offer to help translate.
thank you for your questions, indeed, it is much like pekunio in the concept of spraying redundant copies of every transaction to a number of peers on the network, but the implementation is not a reputation network like wizard rabbit treasurer.
thank you for your questions, that's do-able.
thank you.
thanks datawraith!
thanks for creating the maintenance account, it would have been impossible to do all that without it.
thanks for finding that.
thanks for making that calculator.
thanks for setting this up cdecker.
thanks for testing.
thanks for that survey!
thanks for that, i see what happened.
thanks for that.
thanks for the feedback on this.
thanks for the spanish and french translations!
thanks m0mchil for keeping up on the updates!
thanks madhatter and generica for detailing the instructions for building on freebsd.
thanks soultcer for talking with the freenode staffer.
thanks to everyone for the quick response!
thanks to martti malmi (sirius-m) for his coding work and for hosting the new site and forum, and thanks to new liberty standard for testing the linux version.
thanks virtualcoin, that's a perfect comparison.
thanks!
thanks, i hadn't seen that yet.
thanks, i've been really busy lately.
thanks, that worked, i got file manager installed with ssh.
thanks.
that also goes for each thread too.
that big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with.
that block is invalid and rejected.
that brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01?
that code was a bad idea anyway, i'm deleting it.
that concept doesn't have much analogy in the real world.
that could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent.
that could happen if threadsockethandler or threadmessagehandler is hung or crashed or blocked.
that covers a large range of possibilities.
that gives you the total count of network nodes (except tor nodes).
that hasn't been a problem in practice, the network is very thoroughly connected.
that is probably the best way you could help.
that is what happens if you copy wallet files around.
that is, each of bitcoin and bitdns have their own chain links inside their blocks.
that makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.
that may be an improvement, depending what the side effects are.
that means a lot coming from you, hal.
that means it's no longer necessary to delete blk*.dat before upgrading.
that means the status bar at the bottom needs to say at least 33000 blocks, like "x connections  33200 blocks  x transactions".
that means you generate only 55% as many coins for the same amount of work.
that might be clearer.
that might be payment for computer time.
that might work surprisingly well.
that must be it then.
that narrows it down a lot.
that one $100 bill allowed 10 different people to act like their 5000 bitcoins were equivalent to $100.
that only makes it worse.
that seems surprising to me.
that should give it time for my node to connect to you and i could see what it says on my side and correlate it with your debug.log.
that shouldn't make a difference though.
that voip company essentially said so in a recent post.
that was the achilles heel of chaumian systems; when the central company shut down, so did the currency.
that way if someone does a backup while bitcoin is running, they'll get a wallet.dat that is valid by itself without the database transaction logs.
that way the number of domains would grow with demand and the number of people using it.
that works.
that would be a big help.
that would be a smaller project than the pooled keys, so maybe it could be done first.
that would be great!
that would be great.
that would be like every usenet user runs their own nntp server.
that would be more automation friendly.
that would be more powerful if there was also some narrow product market to use it for.
that would be nice at point-of-sale.
that would be very natural and users could see and verify that what they entered is who they intend to pay.
that would confirm that all the cpu time it's taking is generate, which is idle priority already.
that would introduce security issues.
that would make a significant difference to sha if it could hold most of the 16 state variables in registers.
that would put it at 181.54. the target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
that would require a difficult level of integration of custom code with the bitcoin server though.
that would still be more than 100 times the average transactions per block.
that'll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase.
that's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
that's a better fit and can produce a better looking website than a wiki.
that's a dangerous thing to say and you should delete that bullet point.
that's a good domain.
that's a good idea to go in a more web-publishing cms type direction like drupal.
that's a good idea.
that's a good optimisation.
that's a good point that since you know how many coins exist and how fast new ones are created, you could set a support price based on the amount of legacy currency you have and be sure you'll have enough to meet all demands.
that's a good point, i believe you could run with generation off if you don't have sse2.
that's a great idea.
that's a lot of time for them to come up with better stuff.
that's a really well written walkthough.
that's already possible.
that's amazing... so are you saying you use 128-bit registers to simd four 32-bit data at once?
that's going to be more of a selectcoins thing.
that's good, is it running fine on freebsd?
that's great because that's where i have less expertise.
that's great!
that's great, any help is really appreciated!
that's great, i could probably get a donor to send currency to you which you convert to euros and pay out through methods that are convenient for users.
that's great, that's a good step forward.
that's interesting.
that's kind of interesting as an upside-down bar chart of how many blocks were produced each day.
that's not due to normal initial download time.
that's not going to make it so people can just generate all the bitcoin they want for spending.
that's not necessarily easy or a given.
that's not possible.
that's offset by the fact that the incentive to attack it is also low when it's small.
that's one of the reasons for transaction fees.
that's right.
that's strange, i've seen firefox 3.5 on xp anti-alias large fonts.
that's strange...  are we sure that's the same thing?
that's the better compiler, i only used vc for debugging.
that's the branch it'll be trying to make a block out of, which is all it needs the pool for.
that's the easy part.
that's the first i've heard anyone say i5 was slower.
that's the first time i've seen this error.
that's the right way to do it as rix says.
that's true, with the send-to-ip option, you are sending to whoever answers that ip.
that's used everywhere, the conversion needs to work.
that's what it does, it returns true/false.
that's what it's for.
that's when it prints "getnextworkrequired retarget" in debug.log.
that's when it's flushing.
that's why generate doesn't run when you're not connected.
that's with mingw.
the "addr" system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline.
the "create and edit menu items" page comes up blank for me: http://bitcoin.sourceforge.net/nexus/menu_items.php?menu_id=2 you try it, i'm stumped.
the "generated (not accepted)" normally happens if two nodes find a block at close to the same time, one of them will not be accepted.
the -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
the .dat files are fine, their format shouldn't ever change.
the 0.2.0 release did not build on 64-bit yet.
the 15% speedup from 32-bit to 64-bit linux is more of a mystery.
the 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right.
the 3 or 4 fastest nodes' dominance would only be proportional to their share of the total cpu power.
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.
the 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000.
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 accounts-based commands: move, sendfrom and getbalance <account> will be in the next release.
the address space is effectively unlimited.
the addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.
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.
the adjustments are every 2016 blocks.
the advanced questions i've received have mostly been unique per person and best answered individually.
the advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops.
the advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you're downloading them from.
the algorithm aims for an average of 6 blocks per hour.
the article could be as simple as something like: "bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."
the asm sha-256 is about 48% faster.
the attached file: bitcoin-0.1.1.rar (filesize 2,132,686) is the version where i deleted the mapaddresses.count line, and that should be the safest version.
the automatic adjustment happened earlier today.
the average total coins generated across the network per day stays the same.
the average transaction, and anything up to 500 times bigger than average, is free.
the average work required is exponential in the number of zero bits required and can be verified by executing a single hash.
the bad chain is also slowed down as more nodes upgrade.
the basic escrow: the buyer commits a payment to escrow.
the best 16x16 with full alpha channel is in src/rc/bitcoin.ico.
the best thing we can do is make sure there's cash available to cash out and support and steady the conversion rate.
the bitcoin address is abbreviated so you can see the label that you set in the receiving tab of the address book.
the bitcoin address would not be used for the transaction, only for authentication.
the bitcoin binary in the distribution static links the wxwidgets library, and its shared links (openssl and gtk) are included in ubuntu, so it can run without needing to be a .deb to pull down dependencies.
the bitcoin icon has 5 different versions but i couldn't figure out how that works in xpm so i only put the biggest one.
the bitweaver forum feature is just too lightweight.
the blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them.
the block chain was a clean straight line without branches, and there was only one known version of the locked block.
the block count people are looking for is the number of blocks they've downloaded.
the blockchain is designed so that the whole blockchain is not needed to verify itself.
the blocks increase linearly, it'll be decades before it's millions.
the blocks number in the status column next to your transactions is the number of blocks that have come after that transaction.
the blog is i've also been busy with other things for the last month and a half.
the branch that it currently thinks is the best branch.
the bug is also what caused bitcoin.exe to fail to exit.
the build for this is version 0.3.19.
the bulk of their data is hashes and keys and signatures, which are uncompressible.
the buyer can release the payment at any time after that, which could be never.
the buyer can't benefit by failing to pay.
the buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
the caller needs to identify the transactions of interest, that's where the one-bitcoin-address-per-transaction model helps.
the captcha url has mycode=4 added to it, and the register page has extra hidden mycode=2 through 5 images so any automated thing wouldn't know which one to pick.
the cash register displays a qr-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.
the central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust.
the central code: any comments on these decisions?
the challenge is, how do you prove that no other spends exist?
the change is in the requestee's side, so this functionality won't be visible until your initial block download is coming from a node that has the new version.
the changes are: - it does not return work when you submit a possible hit, only when called without parameter.
the characters are rarely used upper ascii, not valid as utf-8, and produce a large 4-byte int at any alignment.
the circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.
the classic version is the only one to work on mac os version 8. the carbon version may be built either as cfm or mach-o (binary format, like elf) and the former may run under os 9 while the latter only runs under os x. finally, there is a new cocoa port which can only be used under os x. to summarize: if you want to test for all mac platforms, classic and os x, you should test both __wxmac__ and __wxcocoa__.
the clock part will be covered in the next release (0.3.11 or higher).
the code assumes little-endian throughout and was written with the intention of never being ported to big-endian.
the code is completely 32-bit.
the code/message members have become standard in later json-rpc specs.
the coins are gradually being released to the networks nodes based on the cpu power they contribute.
the coins are gradually released to the network's nodes based on the cpu power they contribute, so you can get a share of them by contributing your idle cpu time.
the combination of the two gets us the best of both worlds and more total robustness.
the combined speedup is about 2.5x faster than version 0.3.3. i guess it's using sse2.
the command line to use a different data directory is for example, on linux, the default directory is (don't use ~) you shouldn't normally have any need to use this switch.
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.
the communications thread was blocked and failed to exit.
the community needs to be united to bring it along, even though i can't be there anymore.
the compile dump had 2 warnings (that were 20 lines long) and 2 link errors.
the complete list of defines is at malloc.h is only needed on windows, i'll move that into the __wxmsw__ section before it causes any more trouble.
the complete selection of links is below if you want a different one.
the connectivity bug could have caused a generated block not to be accepted if the node wasn't able to broadcast at the time.
the cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services.
the cost would be an order of magnitude less than the billions in banking fees that pay for all those brick and mortar buildings, skyscrapers and junk mail credit card offers.
the cpu usage is 100% when you're generating coins.
the credential that establishes someone as real is the ability to supply cpu power.
the crucial file to backup is wallet.dat.
the crypto++ asm sha-256 works with gcc on linux and windows (mingw).
the ctrl+alt+f[1-8] thing never worked on this computer.
the current balance of the account is (credit - debit).
the current banking model is already tested and the actual loss percentage is known.
the current sending by ip is not very useful: it connects to the ip, so you'd like to use tor for anonymity, but then it can totally be eavesdropped and man-in-the-middled.
the current system where every user is a network node is not the intended configuration for large scale.
the current threshold is 200kb per block, or about 1000 transactions per block.
the data is lost.
the data is mostly hashes and keys and signatures that are uncompressible.
the data is stored in a transactional database dbm, so website as easily as dropping coins in a vending machine.
the database default had it writing each block to disk synchronously, which is not necessary.
the database doesn't like the relative path.
the database unfortunately names its files "log.0000000001".
the database/log.
the db exception is uncaught, so it'll stop the program if you get it.
the db.h:140 class db no member named "exisits" is stranger.
the db::open/close errors confirm the pattern.
the design and coding started in 2007. that's a good approach for mobile.
the design outlines a lightweight client that does not need the full block chain.
the design supports a tremendous variety of possible transaction types that i designed years ago.
the design supports letting users just be users.
the details about how to backup your wallet files is in the q&a dump and also it's explained in readme.txt and definitely belongs in the faq.
the developers of this pretender-bitcoin claim to be following my original vision, but nothing could be further from the truth.
the difficulty adjusts proportionally to the total effort across the network.
the difficulty can adjust down as well as up.
the difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.
the difficulty is controlled by a moving average that compensates for the total effort being expended to keep the total production constant.
the difficulty is multiplied by 14/(actual days taken).
the difficulty quadrupled a few minutes ago to 181.54.  it's going to take typically about a week to generate now.
the display showing the balance in the dispenser encourages people to top it up.
the distro packages of 2.8 are utf-16, so they just trip people up.
the docs say it uses memory mapped files.
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.
the double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting.
the down side is that it's vulnerable at the beginning when it's small, although the value that could be stolen should always be smaller than the amount of effort required to steal it.
the download links are on bitcoin.org then all the cpu time is the generate thread, which definitely runs at the lowest possible priority, idle priority.
the ease of getting a small amount of bitcoin may help bootstrap an ecosystem of sellers of micropayment sized online goods selling to that market.
the easy solution i took was to look at the wxwidgets source code and see how they did it.
the easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as: user's near-hits/total near-hits from everyone that would be easier and safer to start up.
the ec-dsa key size is very strong (sized for the future), we don't practically have to worry about a key getting broken, but if we did there's the advantage that someone expending the massive computing resources would only break one single transaction's worth of money, not someone's whole account.
the edited and updated .po files are attached.
the end of your debug.log file might show the last thing it was doing before it crashed.
the entire network is making sure to re-integrate your transactions again.
the error it gives is extremely vague.
the errors were: those are probably due to switching to the release build of wxwidgets instead of debug.
the escrow feature will help but not solve everything.
the eventual solution will be to not care how big it gets.
the exception is when using a bitcoin address, everything sent to the same bitcoin address is on the same key, which is a privacy risk if you're trying to be anonymous.
the exchange service doesn't handle any real world money.
the existing transaction line will change.
the existing visa credit card network processes about 15 million internet purchases per day worldwide.
the external api we have, in rpc.cpp, the usage documentation is in the help string.
the extra wattage consumed goes straight to your power bill, and the value of the bitcoins you produce would be something less than that.
the fact that clients have to keep the entire history reduces the privacy benefit.
the fallback is our own seed system.
the feature isn't enabled or used yet, but the support is there so it could be implemented later.
the fee the market would settle on should be minimal.
the files are in "%appdata%\bitcoin", that's the directory to firefox store their settings files there, despite the headwind of it should be safe from loss if there's a crash or power failure.
the files are there on the admin side, but not on the user side.
the first 1kb is free, small transactions are typically 250 bytes.
the first default one is labelled "your address" when it's created.
the first step of being easy in one direction, bitcoin-of established value, goes a long way.
the first strcat in the registry code should be strcpy, otherwise it would fail intermittently.
the first time you access the site on a given day, you pay for 24 hours of access.
the first transaction in the block is a special one that creates a new coin owned by the creator of the block.
the first two are run normally, the rest are run like: another big jump in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days ago.
the fix for the thread priority level on linux is available in the 0.3.1 release candidate here: that's surprising that we've never heard of that before now.
the fix is now available on svn, file util.cpp.
the focus for bitcoind so far has been more on backend support for websites.
the foreground is now exactly the same colour as the bc in the old one.
the formula is based on the time it takes to generate 2016 blocks.
the formula is hardcoded in the program and every node does the same calculation to know what difficulty is required for the next block.
the forum doesn't have a built in file upload/edit admin feature, it's added separately as the smf file manager mod.
the forum link should be changed to: thanks, i haven't settled on a theme yet.
the forum sure is taking off.
the frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.
the functional details are not covered in the paper, but the sourcecode is coming soon.
the further back it is, the further before the branch point it may be.
the future plan for sending to an ip is to make it a bitcoin address plus ip, like: i need suggestions for the separator character.
the gating factor is the indexing while it downloads.
the gcc debug version is attached.
the generate thread only changes to higher priority for less than a second every few days.
the generate threads run at prio_min.
the german translation is uploaded to svn.
the good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.
the hassle of buying the other online currencies is too much for buying a small amount.
the header contains a hash of the transactions (the merkle root) and is only updated occasionally.
the heat from your computer is not wasted if you need to heat your home.
the highest version when the deadline hits gets recorded.
the http response could simply be html with the javascript equivalent of the back button, sending it back to the page.
the hunt brothers famously bankrupted themselves trying to corner the silver market in 1979: "brothers nelson bunker hunt and herbert hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.
the icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes.
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.
the idea of an option to view/hide unaccepted blocks is a good one, as well as view/hide all generated blocks so you can more easily see incoming transactions.
the idea was the main part.
the important thing is to have ssl available for those who need it.
the incentive can also be funded with transaction fees.
the incentive is to get the rewards from the extra side chains also for the same work.
the incentive may help encourage nodes to stay honest.
the initial purpose of block size limit is to limit the bandwidth so that it is easy for people to record the blockchain on their computer rather than on some cloud-based center authorities.
the inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.
the instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.
the interface has a few changes: getwork [data] if [data] is not specified, returns formatted hash data to work on: "midstate" : precomputed hash state after hashing the first half of the data "data" : block data "hash1" : formatted hash buffer for second hash "target" : little endian hash target if [data] is specified, tries to solve the block and returns true if it was successful.
the interior hashes do not need to be stored.
the internet is a brutal, rough and tumble place.
the inventory-request-data scheme introduces a little latency, but it ultimately helps speed more by keeping extra data blocks off the transmit queues and conserving bandwidth.
the ip address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.
the ip selection process is designed to limit vulnerability to address flooding.
the ip was pingable during the outage.
the irc code is looking for various phrases to see when the server is ready to receive your nick, but it's not looking for that particular phrase.
the irc has the advantage that it lists nodes that are currently online, since they have to stay connected to stay on the list, but the disadvantage that it's a single point of failure.
the irc server's response doesn't look like it was disconnecting you for that.
the issue of bitcoin.exe still running after you close it is a known issue.
the json api functions are complete.
the json-rpc interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.
the json-rpc methods that return errors during an alert are: thanks for clearing that up.
the key was gavin's idea for prioritising transactions based on the age of their dependencies.
the khash/sec meter stayed stuck because it couldn't get any cpu to update it.
the largest free transaction will be 60kb, or about 27,000bc if made of 50bc inputs.
the largest icon that still looks good is the 20x20 one which is used for the tray icon in gnome.
the last thing we need is switchover hassle on top of the slashdot flood of work we've got now.
the latest svn version has a khash/s display.
the lifetime of the (for instance) ctxdb object is only to support database transactions and to know if anything is still using the database at shutdown.
the lightning thing is also not a perfect solution, as it made a second level architect, it need more trust and may encourage center authority and paypal-like companies.
the lightweight client can send and receive transactions, it just can't generate blocks.
the lightweight client is not implemented yet, but the plan is to implement it when it's needed.
the lines it's tripping on: so it's acting like nothing is defined, not even map and vector.
the link: "win32 cpu cycles vs 'live protection' engines" for bitcoinfx, live protection was keeping it from getting cpu for generating coins.
the links to sites to help set up 8333 port forwarding is great.
the linux 64-bit version includes a change to the cpuid 4-way 128-bit sse2 autodetect for amd in 64-bit mode, if you'd like to test that and see if that's better.
the linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind.
the linux version includes tcatm's 4-way sse2 sha-256 that makes generating faster on i5 and amd cpu's.
the linux version includes tcatm's 4-way sse2 sha-256 that makes generating faster on i5, i7 (with hyperthreading) and amd cpu's.
the linux version is 64-bit only.
the linux version looks fully stabilized to me.
the linux version, setup exe, tor option and better website/forum will all increase the percentage of visitors who can use it, and the autostart and minimize to tray will increase how many keep running it.
the list/getreceivedbyaddress/label functions are the only way to do it reliably.
the logo's a little too disco/web-1990's.
the longer waited, the more priority accumulates.
the longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of cpu power.
the loss in practice would be far lower than with credit cards.
the mac version is still 0.3.10.1. i updated the first post to be more specific.
the main addition in this release is the accounts-based json-rpc commands that gavin's been working on (more details at then how do you cope with the issues i listed in the message you quoted?
the main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history.
the main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history.
the main benefit is that blocks will be equal to the block number of the current best block.
the main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two.
the main thing holding online currencies back is the lack of an easy way to get a small amount of currency.
the majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.
the makefiles have -dgui to control whether the gui is used.
the margin is 2 hours.
the marginal cost of gold mining tends to stay near the price of gold.
the meaning of the number isn't as strong for blocks as for transactions.
the menus quickly quit working and it doesn't repaint when it's supposed to unless i resize it, and the ui is getting some segfaults.
the merchant would only have to monitor for a minute or two until most of the network nodes have his version and it's too late for the thief's version to catch up and reach many nodes.
the message "warning: this block was not received by any other nodes" occurs when bitcoin broadcasts a block, but nobody confirms they received it.
the message would have to include a salt so nobody could brute force the hash to reveal a short message.
the messages could be signed with the bitcoin address keypairs to prove who they're from.
the mit license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
the model where you assume you only need to see new transactions because you've already seen previous transactions is not true.
the money is leveraged better that way too.
the money is never truly burned.
the more burden it is to run a node, the fewer nodes there will be.
the more standard wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like electronic currency or electronic cash.
the most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade.
the msg_dontwait fixed the root cause, it's not having to terminate and restart the thread.
the name printed there is what's associated in your address book for that electronic currency in some way, now that we know a way to do it button to the right of your bitcoin address.
the nature of bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.
the necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.
the neighbours request the items they don't have yet.
the network infrastructure can support a full range of escrow transactions and contracts, but for now the focus is on the basics of money and transactions.
the network is robust in its unstructured simplicity.
the network itself requires minimal structure.
the network keeps the outpoint and the first valid inpoint that proves it spent.
the network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate.
the network should be generating close to 6 blocks per hour now.
the network threads don't care that the ui isn't there.
the network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.
the network works in parallel to generate a chain of hashcash style proof-of-work.
the networks need to have separate fates.
the networks wouldn't need any coordination.
the new efficient single-pass algorithm is orders of magnitude quicker.
the new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.
the new safety feature displays a warning message in the status bar and locks down rpc if it detects a problem that may require an upgrade.
the new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.
the new threshold puts it at around 11,000 btc for sending generated coins.
the node that generates the block that contains the transaction gets the fee.
the nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
the number of connections won't be a good gauge of the size of the network any more.
the old forum can still be reached here: i'll repost some selected threads here and add updated answers to questions where i can.
the old names are still there so as not to break existing code, but they're deprecated.
the old screenshots of 0.1 are very outdated.
the one exception is wallet.dat, which i still close after writing is finished so i can flush the transaction logs into the dat file, making the dat file standalone.
the one in bitcoin-0.1.1-exe-dbg.rar is the same build as in bitcoin-0.1.1.rar.
the one that you've had available for a while has been vetted and is the best choice.
the ones ending in port 8333 can receive connections.
the only choices given are those that the receiver is expecting.
the only disadvantage is that you have to trust the site, but that's fine for pocket change amounts for micropayments and misc expenses.
the only exception to that is the manual checkpoints i've added.
the only other ui is a message box in checkdiskspace if it runs out of disk space.
the only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
the only place where it uses floating point to represent money is returning a value in json-rpc.
the only problem now is the db exceptions he's getting.
the only safe place is http://www.internic.com/whois.html i have an idea for a workaround, but it depends on what files the errors are on.
the only thing i can think of is if the socket is receiving a spew of characters.
the only thing i can think of is to see if there are other versions of mingwm10.dll you can get.
the only thing other than installing themes was the .htaccess file (which really is needed, it didn't work in the global config file).
the only time it automatically adds a label is a blank one when you send to a new address.
the only time it should fail to bind is when the program really is already running.
the only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the ui.
the only way to confirm the absence of a transaction is to be aware of all transactions.
the only way to show the network how much cpu power you have is to actually use it.
the only workaround for you right now would be to exit and restart more often.
the op's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case.
the op_blocknumber transaction and all its dependants would become invalid.
the options i used are in build-unix.txt.
the original will be good for scaling to custom sizes between 48 and 500 but not smaller.
the os isn't supposed to let you increase priority, so the prio_min ought to leave it at priority 0. it doesn't work with wxwidgets 2.8, it needs wxwidgets 2.9.  unfortunately, there isn't a debian package of wxwidgets 2.9 yet.
the other threads rarely take any cpu and run at normal.
the other way, creating a runas registry entry, is not easily visible or editable by users, i've never liked that much.
the overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments.
the owner of a coin is just whoever has its private key.
the owner of the node would decide the minimum fee they'll accept.
the p2p file sharing networks seem fairly successful at getting a large percentage of their users to set up their firewalls to forward a port.
the paper was published in 2008. someone needs to correct wikipedia; it incorrectly says the paper was published in 2009.  the paper was released earlier than the software.
the payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
the payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
the payment processor has connections with many nodes.
the payment sequence does have a step where the receiver verifies the order before accepting it.
the performance numbers posted from a via c7's hardware sha-256 weren't astronomical.
the plan is to implement an ip + bitcoin address option that would have the benefits of both.
the possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use.
the possibility to cash out through them would help support the value of bitcoins.
the premise is false.
the price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator.
the price of any commodity tends to gravitate toward the production cost.
the priorities converted from windows priorities were probably from a table like this: "the following table shows the mapping between nice values and win32 priorities.
the problem is i used prio_min, i should have used prio_max for the lowest priority.
the problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.
the problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
the process has the potential to establish the pow token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters.
the program loads the .mo file at runtime and reskins all the strings.
the project needs to grow gradually so the software can be strengthened along the way.
the proof-of-work chain is the key to solving the byzantine generals' problem of synchronising the global view and generating computational proof of the majority consensus without having to trust anyone.
the proof-of-work difficulty is currently 45.38.
the proof-of-work involves scanning for a value that when hashed, such as with sha-256, the hash begins with a number of zero bits.
the proof-of-work is a hashcash style sha-256 collision finding.
the protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received.
the public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.
the question could be something like "what if i have 0 connections" and that could be the answer that it might be because the nodes you can connect with is limited if you don't set that up.
the race between the honest chain and an attacker chain can be characterized as a binomial random walk.
the race is to spread your transaction on the network first.
the random seed is very thorough.
the ratio of fake mailboxes to real people could become too high for spam to be cost effective.
the reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.
the reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.
the reason i didn't implement listtransactions is i want to make sure web programmers don't use it.
the receiver generates a new key pair and gives the public key to the sender shortly before signing.
the receiver of a payment does a template match on the script.
the receiver will be alerted when that happens, but the sender hopes it will be too late.
the receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.
the receiving copy doesn't have to be online at the time.
the recent adjustment put us back to close to 6 blocks per hour again.
the recipient doubleclicks it can already be used for pay-to-send e-mail.
the recipient doubleclicks on the transaction to see the full message.
the recipient of a bitcoin payment is able to check whether it is the first spend or not, and second-spends are not accepted.
the recipient waits until the transaction has been added to a block and z blocks have been linked after it.
the recommended ways to do a payment for an order: 1) the merchant has a static ip, the customer sends to it with a comment.
the recourse is to refuse to ever release it, essentially burning the money.
the rest of the 64-bit compile errors i was getting were in wxwidgets 2.8.9, so i started working on supporting wxwidgets 2.9.0. wxwidgets 2.9.0 is utf-8.
the rest will be client nodes that only do transactions and don't generate.
the rest will be lightweight clients, which could be millions.
the resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent.
the risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
the rng is the openssl secure random number generator.
the rpc methods return a json-rpc error with the error description "safe mode: " followed by additional text specified by the alert.
the safety lockdown cannot stop generation or it would create an attack possibility.
the safety lockdown detected the problem and was displaying "warning: displayed transactions may not be correct!"
the sample code should be the simplest possible with the minimum extra stuff to make it a working site.
the screen just goes haywire.
the script is actually a predicate.
the second signer can't release one without releasing the other.
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.
the select error is not a big deal, but it led the communications thread to get blocked on a socket that should have been in non-blocking mode but wasn't.
the seller can see that the funds are committed to his key and can't be sent to anyone else.
the seller has the option to release the money back to the buyer.
the seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
the seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller.
the seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it.
the send dialog is resizeable and you can enter as long of a message as you like.
the serialization format we have is as dead simple and flat as possible.
the serialization overhead is very small, usually 1 byte for size fields.
the side accepting the connection just needs to withhold from sending anything until it receives a valid handshake.
the simplification is intentional.
the site at bitcoin.org was designed in a more professorial style when i was presenting the design paper on the cryptography list, but we're moving on from that phase.
the site layout is looking nicer.
the size of the payment is too small for the effort to steal it.
the slow start is consistent with the slow download speed.
the socket isn't returning an error, just zombie without notice.
the sockets are marked non-blocking already, so i don't understand why.
the sockets code is send/recv stuff which i think is the same as unix because microsoft ported sockets from bsd.
the software can generate a new bitcoin address whenever you need one for each payment.
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.
the software is designed to support things like this.
the software is still alpha and experimental.
the software would be programmed to start using a new hash after a certain block number.
the software would have to know your future plans to know whether to spend your priority now or save it for later.
the solution is an extra dialog when sending, something like "this is an oversized transaction and requires a transaction fee of 0.20bc.
the solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.
the solution we propose begins with a timestamp server.
the source is included in the main download.
the space people may just be getting lazy using their language's split function.
the specialbuild version i posted here looks for model 4 or higher.
the speed of initial download is not a reflection of the bulk data transfer rate of the protocol.
the spent fee goes to the miners in the next block fee.
the ssl also makes it safe for tor users.
the startup folder has the advantage that the end user can see it and manually remove it with the regular ui (not regedit) if they already blew away the bitcoin directory and its uninstaller.
the status can go to "#/offline?"
the status number would no longer be coordinated with the maturity countdown on blocks either.
the steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation.
the steps to run the network are as follows: 1) new transactions are broadcast to all nodes.
the success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. the probability of an attacker catching up from a given deficit is analogous to a gambler's ruin problem.
the supply of gold increases by about 2%-3% per year.
the svn now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually.
the svn version now uses irc first and if that fails it falls back to a hardcoded list of seed nodes.
the svn was first buildable on 64-bit with wx2.9.0 on 28 january 2010. hopefully they'll have a wxwidgets 2.9.0 debian package someday.
the system is entirely decentralized, without any server or trusted parties.
the system is secure as long as honest nodes collectively control more cpu power than any cooperating group of attacker nodes.
the system is wide open to copying plaintext credit card numbers and account numbers, and they deal with it by reversing the transaction after the fact.
the system works for physical goods that have to be delivered somewhere, and services which can't be resold.
the target is 144 blocks per day.
the terminate on linux is pthread_cancel, which throws it into c++'s exception handler.
the thief would not be able to broadcast during the monitoring period or else the merchant's node would receive a copy.
the things in the registry key tend to be devious hidden bloatware.
the thread calls we were using didn't have terminate, so i created our own wrappers in util.h to use createthread on windows and pthread_create on linux, instead of: _beginthread is windows only and lacks terminate boost::thread is really attractive, but lacks terminate wxthread requires you to create a class for every function you might call (yuck) i created a forum on zetaboards, invisionfree's new site that they're migrating to.
the thread list only fits about 4 threads on a page, posts are treated like news articles or blog posts with reply comments at the bottom.
the threading is _beginthread which is part of the standard c library.
the threshold can easily be changed in the future.
the threshold should probably be lower than it currently is.
the threshold was around 26,000 btc for transactions made of 50 btc generated coins.
the tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
the time for your block to mature will always be around 20 hours.
the timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.
the timing works out well because we can switch to the new forum now and release the drupal site later when we're ready.
the tor exit node can see the text of your message and potentially mitm you.
the traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.
the transaction fee to the block creator uses a special trick to include the transaction fee without any additional size.
the transaction has already been signed and recorded.
the transaction only tells who it's to.
the transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.
the transfer is immediate if you send by ip address.
the transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces.
the trylock bug is unrelated to the db stuff.
the two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.
the ui will show it rounded down.
the uncertainty about what the average loss percentage will be is greater than the likely loss percentage itself.
the user accounts on drupal appear to be pretty weak.
the user would send to domain.com (or is ok too).
the usual scam against a merchant that doesn't wait for confirming blocks would be to send a payment to a merchant, then quickly try to propagate a double-spend to the network before the merchant's copy.
the usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model.
the utf-16 version is the "unicode" version provided in the debian package.
the utility of the exchanges made possible by bitcoin will far exceed the cost of electricity used.
the value of bitcoins would be relative to the electricity consumed to produce them.
the vast majority of gold sits unused in vaults, owned by governments that could care less about its prettiness.
the wait function on linux is: if that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
the warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you.
the way it is now, it's whoever builds this gets it.
the way it retrospectively fans out, they might end up seeing a majority of the history.
the website needs to be updated to say tcp port 8333. the port forwarding is so other nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes.
the whole design is all about preventing that from working.
the wine incompatibility deep inside berkeley db is unfixable.
the work per domain could be on a schedule that grows with moore's law.
the workaround is to needlessly call mapaddresses.count in the main thread once and it's fine from then on.
the workaround is to open the database handles and keep them open for the duration of the program, which is actually the more common thing to do anyway.
their code is too large to read and be sure that there's no way to form an input that would do something unexpected.
their date can change, their order can change.
their location on disk is indexed by cblockindex objects in memory.
their massive overhead costs make micropayments impossible.
their number of confirmations would start over.
then a backup will last forward for a long time.
then a separate command line utility to communicate with it to do things.
then an attacker would still need a substantial portion of the network's power to benefit from a dos attack.
then it must be something you're doing differently with building or configuring wxwidgets.
then something more specific was wrong.
then strong encryption became available to the masses, and trust was no longer required.
then we can -addnode= them and make sure to connect to at least one 0.3.10 node.
then we would know which thread the problem is in.
then we wouldn't have to explain the 10,000.20bc transaction, but may still have to explain who the transaction fee goes to.
then you could earn a nice profit by setting up pay-per-send e-mail addresses and collecting all the spam money.
then you must also be against the common system of payment up front, where the customer loses.
then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key.
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.
there are 4 libraries for c++ but they're all big and hard to build, dependencies, license issues.
there are a few other issues we need to look at fixing in 0.3.1 before making a release.
there are a lot of things you can say on the sourceforge site that i can't say on my own site.
there are a number of ideas to try to improve things later.
there are almost no buffers.
there are command line options: bitcoin -addnode=1.2.3.4    to tell bitcoin about a node to connect to bitcoin -connect=1.2.3.4    connect only to the specified node(s) you can use more than one of these, for instance bitcoin -connect=(first to try) -connect=(next to try) ... you can specify non-routable ips with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that.
there are debian packages available for some of the dependencies instead of having to compile them ourselves: i need to see if berkeley db or boost have packages.
there are donors i can tap if we come up with something that needs funding, but they want to be anonymous, which makes it hard to actually do anything with it.
there are enough seed nodes now that many of them should still be up by the time of the next release.
there are few p2p systems that only need broadcast.
there are json-rpc libraries for all the major languages.
there are many variations of these cards.
there are more coming.
there are no changes to the way it handles wallet.dat.
there are no temporary files.
there are normally 1 to 3 other nodes besides you that can accept incoming connections, and existing nodes that already know you would eventually connect to you.
there are now "sending" and "receiving" tabs in the address book.
there are other things we can do if necessary.
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.
there are some libraries like chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want.
there are some scenarios where a usenet or google group could be used as a supplemental defence.
there are two ways to send money.
there aren't many .onion addresses in use for anything because the user has to go through a number of steps to create one.
there could be millions of spv clients.
there could still be some existing user accounts created before the registration requirement being used by spammers.
there is a limited supply of money.
there is extreme prejudice against spam solutions, especially proof-of-work.]
there is never any need to run two on one machine as coin generation will now use multiple processors automatically.
there is never the need to extract a complete standalone copy of a transaction's history.
there is no extra freedom in the way the input stream is formed.
there is no reliable way to do it that way and make sure nothing can slip through the cracks.
there is no reliance on identifying anyone.
there is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work.
there is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory.
there is only one global chain.
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"}.
there is versioning so upgrades are possible.
there isn't an off-line mode where double-spenders are caught and shamed after the fact, because that would require participants to have identities.
there may be something i need to do to make sure it doesn't try to connect to itself again right away after disconnecting.
there may be very recent stuff being written by reporters who heard about it from the slashdot article.
there ought to be a more definite separator between key and value that suggests assignment.
there should be a 0.3.1 release for this soon.
there should be a link to that optional step, add your ip to this list now that you can accept incoming if you're static.
there should not be any signed int.
there shouldn't be any other crypto in there other than sha.
there was a change in getminfee, but i can't see how it would cause this.
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.
there was a discussion of the design on the cryptography mailing list.
there was a discussion on this.
there was an older one that's been running for a long time that publishes its hashes to usenet.
there wasn't anything there when i started.
there wasn't time to do a careful implementation of this at the time.
there wasn't time to investigate at the time.
there were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!
there were some issues in 0.1.5 where the initial block download could get bogged down.
there will be a proxy setting in version 0.2 so you can connect through tor.
there will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can.
there will only be more than one thash[7]=0 in one out of 134,217,728 cases.
there would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases.
there would need to be some changes on the bitcoin miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher.
there you go, we could easily do it the same way, like: <bitcoinaddress>;amount=<amount> bitcoin can answer port 8330 on local loopback just as it does for json-rpc on 8332.  it would give an http answer.
there'll be enough posts to bump.
there's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.
there's a 32-bit linux binary that can be run on 64-bit ubuntu if you "sudo apt-get ia32-libs".
there's a blog writer who wants to write a story about bitcoin, but i don't have time right now to answer his questions.
there's a chance it might still go through.
there's a moving average that compensates for the total effort being expended so that the total production is a constant.
there's a possible design for far in the future: you intentionally write a double-spend.
there's a separate public/private keypair for every bitcoin address.
there's a several step procedure you can do to run a password utility on unix and e-mail request an account that you could login with, but that's getting pretty complicated.
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: 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.
there's a small transaction fee for very large transactions.
there's a thriving business in those services, but i've always thought the standard payment methods are at odds with privacy minded customers.
there's a transaction fee of 0.01 per kb after the first 1kb for oversized transactions.
there's a turnover churn in these free hosting sites.
there's a wide enough difference between normal users and flooders.
there's also kids putting it on their parent's power bill, employees their employer, botnets, etc.
there's always going to be one more thing to do.
there's an assert that catches and warns about break.
there's an installer package now that makes it really easy to install mingw.
there's an issue that if you exit and run it again right away, it can't bind port 8333.  the port frees up after about a minute.
there's clearly something about socket handling on linux that's effecting it either way.
there's demand for things that would be nice for adminning headless generators like listgenerated.
there's gold for one.
there's little hope of not repeatedly stumbling over that in the future.
there's more work i should do on the theme, but it's good enough so far.
there's more work to do on transaction fees.
there's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast.
there's no guarantee the system's state won't have to be restarted at some point if it becomes necessary, although i've done everything i can to build in extensibility and versioning.
there's no hope for core/core2 then.
there's no mediator in this simple case.
there's no msg_dontwait on windows, marking the socket as nonblocking is the only way, so if anyone runs the windows version in wine it will have to rely on terminating the thread.
there's no need for reporting of "proof of double spending" like that.
there's no need to circulate a report about it.
there's no point not having one since you can already do it anyway.
there's no reason for shutdown to wait for the com thread, so i made it only wait for the message processing thread.
there's no risk in shutting down while there are unconfirmed.
there's no such thing as being 1% towards solving a block.
there's no time limit.
there's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.
there's no way for it to know who it's from, so the best to you.
there's nothing in the 0.3.1 that would affect these things.
there's nothing to fear about the debug build.
there's nothing to relate it to.
there's nothing wrong with the msvc 6.0 build other than its optimization of the sha routines for generating blocks is slow thanks for starting that topic on asc, your understanding of bitcoin is spot on.
there's nothing your node does during that time to promote the acceptance.
there's one place where it detects sse2 for deciding some block count parameter, but the sse2 stuff is all #ifdef at compile time and i can't see how that would switch at runtime.
there's polled, asking what has been received to the given bitcoin address, and event driven.
there's probably a compiler switch that would tell it to static link it.
there's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.
there's something here in the general area: what we need is a way to generate additional blinded variations of a public key.
there's something weird with the download bar on the right covering things up, like on the new account registration it covers up the entry fields unless you make the browser really wide, and the homepage it covers up the screenshots.
there's something with mingw's optimisation, i'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault.
there's too much bandwidth between the ui and the internal data structures in order to keep the listview control updated, because of the way the listview control works.
therefore, having bitcoin would be the net waste.
these are binaries only.
these are the properties of blinding.
these costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
they also have support for mediawiki if you want it.
they also refresh whenever a new transaction comes in, so l pretty much contains everything in a all the time.
they aren't very big, so it wouldn't hurt to have a lot of them.
they can go to the file sharing networks to steal that.
they can hog the attention within their class c, but not the whole ip address space overall.
they can't send payment until they've been given a correct bitcoin address to send to.
they concede that something is flammable, but argue that it'll never burn because there'll never be a spark.
they could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server.
they could make a smaller version of the site optimized for mobile.
they do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis.
they have wordpress built in, you might not need to set up any database stuff manually.
they just mapped it to wxmutex on non-msw, which does have tryenter, so that mapped in perfectly.
they kind of botched the c++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right.
they may help discover a simplified way of understanding it that makes it more accessible to the masses.
they need the limits to keep it reasonable as a free service, but if we bolt on a bitcoin payment mechanism, the limits could be relaxed.
they only have half the sse2 hardware.
they only have the wchar ("unicode") version of wxwidgets 2.8, which is a disaster because wchar wxstring doesn't convert to std::string.
they only matter in how many transactions they generate.
they probably couldn't have gotten that large of a trade on bitcoinmarket.com.
they probably want something that just generally identifies what it is, not tries to explain all about how it works.
they say it's also watertight to simply check the ip of connections received and disconnect anything not 127.0.0.1.  may as well do both.
they should be recorded in the wallets of everyone who has a transaction depending on them.
they use my old writings to make claims about what bitcoin was supposed to be.
they usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.
they vote with their cpu power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.
they will need to be updated for 0.3.1 soon.
they won't necessarily be watching for incoming transactions to send back.
they worry about per item because it's harder to figure if it might add up too fast.
they would have many well connected network nodes.
they would scan sha such that if they get a hit, they potentially solve both at once.
they wouldn't need to download blocks, just the hash chain, which is currently about 2mb and very quick to verify (less than a second to verify the whole chain).
they'd essentially be reverse-spamming the spammers with automated mailboxes that collect their pow and don't read the message.
they'd essentially be reverse-spamming the spammers with the process has the potential to establish the pow token's value message.
they'll receive the transaction the next time they connect and get the block it's in.
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.
they're clever c files that define graphics in static arrays.
they're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff.
they're only about 500 bytes.
they're only intended for future use.
they're only intended for intrepid programmers who read the sourcecode.
they're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
they're saying smf is better written than phpbb and more reliable, so if i can get smf to look right, that's the preferable choice.
they're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header.
they're supportive of projects like tor so i hope they would probably be friendly to us.
they're the same data that is passed to the scanhash_ functions.
they're unsupported and not intended to be used by users.
theymos already said this...  ecdsa does not support encrypting messages.
think 6 degrees of freedom -- it spreads exponentially.
think of it as a cooperative effort to make a chain.
think of it as a donation to everyone.
think of it like postage by weight.
think something like a credit card processor with a new job.
this adds a -4way switch for tcatm's 4-way sse2.
this adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.
this also includes a partial fix for the slow initial block download.
this brings up a good point.
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.
this can be a temporary solution.
this change is only for blk*.dat and the non-critical addr.dat.
this change is revision 102 of the svn.
this could also have caused bitcoin.exe to fail to exit.
this does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it.
this doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.
this forum, for instance.
this helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
this is a bugfix maintenance release.
this is a common point of confusion.
this is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and i'd rather not go into it, and i don't have to as long as there's only one version.
this is a huge improvement over the old bitcoin.org page.
this is a lot of surface area that nobody uses that doesn't need to be open by default.
this is a minor release to add some dos protection.
this is a must-have feature for the next release so any users that come back to try the new version we hopefully retain this time.
this is a problem that will solve itself.
this is a restructuring of the database handling, so we might find some new deadlocks.
this is a version 2 problem that i believe can be solved fairly satisfactorily for most applications.
this is a very interesting topic.
this is all fixed in 0.1.3.  if you give me your ip, i'll send you some coins.
this is an important safety improvement.
this is an important service so new users can at least get something if generating is too hard.
this is becoming a common problem.
this is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.
this is great, we've already got 3 major languages.
this is in svn rev 142 as version 0.3.11. if you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
this is in svn rev 147. this is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be not strings or other values, so we needed to change this to be correct.
this is inverted from the common timestamp server arrangement, where the chain is on top and then the merkle tree, because that creates one common master chain.
this is just a dump of everything i've answered.
this is needed because you should be able to spend your own change right away.
this is needed to make drupal coexist with the other site the way we want.
this is not implemented and i probably won't have time to implement it soon, but just to let you know what's possible.
this is now fixed in the svn version.
this is on my list.
this is on the to-do list for v0.1.6.
this is one improvement, but there are still more ways to attack than i can count.
this is only enabled if built with gcc.
this is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.
this is single-player computer game based on windows minesweeper version.
this is so you can't stuff it with millions of password attempts in one packet.
this is the case where the merchant will have a server on a static ip and their own domain name and ssl cert.
this is the important clue.
this is the new spec.
this is the point of confusion.
this is the second time i've seen this "live protection" problem reported.
this is the third major release and 1.3 reflects that development history.
this is two timestamp servers not sharing a chain.
this is what i ended up doing in svn rev 139. instead of deleting the bad chain, i added an extra checkblock to connectblock so bad blocks can't get back into the best chain once they're kicked out.
this is what makes me think the people objecting don't know what they're talking about.
this isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.
this link is a moving target, this archive page is just a certain number of days back and the discussion will keep scrolling off to the next page.)
this may only disable it for msvc and gcc.
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.
this means tor users won't need to -addnode anymore, it'll get connected automatically.
this method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.
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 might have been unsafe code, although it would probably always get lucky.
this never got written up proper.
this particular system has dual intel xeon quad-core cpus (e5335) @ 2.00ghz.
this present situation has been very disappointing to watch unfold.
this prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment.
this probably explains why hyperthreading increases performance with -4way.
this probably gets fixed after 0.3.3.  until then, just use single invocation.
this probably requires apache to be restarted after.
this saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.
this should all be working in a few more days.
this should be solved in svn rev 141 and the next release (0.3.11+).
this time we'll have both 32-bit and 64-bit linux binaries, and laszlo is going to build a mac osx release.
this updates your existing .po file you already worked on and adds any news strings.
this version has really stabilized things.
this version has the new priority-based limit on free transaction spam.
this was built on the same os installations as 0.3.0. unfortunately i upgraded to ubuntu 10.04 before 0.3.0.  i will not upgrade anymore.
this way, it'll receive the blocks before the retry timeout, so it shouldn't go requesting it from other nodes unless it actually doesn't receive them or it's too slow.
this will be an absolutely essential feature once things get going, making it so you can lock your wealth up with strong encryption and back it up more securely than any physical safe.
this will be the standard way for website software to do it.
this will only be for linux: please report back your results which doesn't matter because you can't access sourceforge to download the software either.
this will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable: 1) how do you know if a past transaction becomes invalid and disappears?
this windows build has the russian translation in it: it can be phased in, like: it can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
this would be a step better than e-bay.
this would be much higher value traffic well targeted for high paying gold merchant keywords and vpn hosts.
this would encourage users to free up names they don't want anymore.
this would make it mostly repair the situation instead of giving that error message.
this would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.
this would not be hard to do, it just hasn't been implemented yet.
this would solve the problem that if there are multiple networks, they are a danger to each other if the available cpu power gangs up on one.
this wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.
those are hidden, they're not shown in the ui.
those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit.
those coins can never be recovered, and the total circulation is less.
those don't look like anything to worry about.
those few nodes will be big server farms.
those libraries are also much harder to install than ourselves.
those who need ssl i think know to try inserting an "s" after http and see if it works.
threads are processes on linux, so prio_process affects just the one thread sirius-m debugged this, it was 64-bit related.
time within the same class b.  maybe every time the program is run.
timestamp hashes are still already possible: if there's an actual application like bitdns getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.
title changed.
title: electronic cash without a trusted third party thanks for letting me know about your paper.
to accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received.
to add them now at this point, what would be written would just be what's obvious from looking at the function.
to allow value to be split and combined, transactions contain multiple inputs and outputs.
to calculate our progress towards the next one, divide the block total by 2016.  the fractional part is how far we are to the next one.
to compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour.
to connect through tor, you could use: bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216 it's much easier to have a single binary and multiple .mo files.
to control it from the command line, the interface is a command name without any switches, followed by parameters if any.
to enable the rpc server, add the switch -server.
to facilitate this without breaking the block's hash, transactions are hashed in a merkle tree [7][2][5], with only the root included in the block's hash.
to generate: bitcoin -min -gen to get the generated bitcoins, you'd have to copy wallet.dat (with version 0.2) to a machine with a ui, swap in the wallet.dat, run bitcoin and transfer the coins to your main account.
to hand it in to bitcoin, you break off the bitdns branch, and to hand it in to bitdns, you break off the bitcoin branch.
to implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work system similar to adam back's hashcash [6], rather than newspaper or usenet posts.
to make bitcoin addresses short, they are a hash of the public key, not the public key itself.
to make it safer, the exchange site could act as an escrow for the bitcoin side of the payment.
to modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.
to originally connect with tor without connecting normally once to get seeded, you'd have to know the address of an existing node that can accept incoming connections and seed it like this: bitcoin -proxy=127.0.0.1:9050 -addnode=<ip of a node if some nodes that accept incoming connects were willing to have their ip coded into the program, it could seed automatically.
to play it safe, when the ip address changes, the content better stay the same and vice versa.
to protect privacy, key pairs are used only once, with a new one for every transaction.
to release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half.
to solve the proof-of-work problem faster?
to solve the traffic problem, nodes can exchange the„Ç‚†hash stream only and verify it against information provided by full nodes;„Ç‚†the security of the whole blockchain, scalability, and speed can both be achieved.
to solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of cpu power.
to stop it, kill the process, the database won't mind.
to the rest of the world, "log" means delete-at-will, but to database people it means delete-and-lose-everything-in-your-other-files.
to think about what a really huge transaction load would look like, i look at the existing credit card network.
to transfer it, the owner signs the coin together with the public key of the next owner.
to use an analogy, it's more like the step from 32-bit to 64-bit address space.
tor users wouldn't have to worry about how to get seeded, and we wouldn't depend on irc.
total circulation will be 21,000,000 coins.
total is double counted.
total proof-of-work.
trading bitcoin becomes an easier way to trade the ability to claim lr, similar to how paper money was once the right to claim gold.
transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly.
transactions are dynamic.
transactions are written to the database immediately when they're received.
transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.
transactions only transfer ownership.
transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.
transfers by ip address automatically use a new bitcoin address each time.
translatable strings are all enclosed in _(""), and we're using utf-8 on all platforms.
translating it into your home language weakens that argument.
tried that, but it doesn't work for things on the stack.
true, if it happened suddenly.
true, sending by ip through tor trades one problem for another.
true.
try -datadir= last time i tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it.
try __wxosx__ (or see below) "there are two wxwidgets ports to mac os.
try changing line 78 of init.cpp from: if that works, i'll change the source.
try changing the two "unsigned int"s to "size_type".
try it with the attached irc.cpp and net.cpp and send me the debug.log.
try the "-4way" switch to enable it and check if it's faster for you.
try this irc.cpp.
try to address how the rule is satisfied.
try version 0.3.7. it can be built with boost 1.37 or later.
trying it without the db_private flag in rev 153.  we need to keep an eye on what's different.
two new log messages: grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance.
type 2 exposes you to a billion people who can self-select to be attackers and get economy of scale when they bitcoin address doesn't have that vulnerability, although there's sending by ip requests a new public key, so yes, it's vulnerable to type 1 man-in-the-middle.
typical time to get a block is about a week now.
typically a few hundred right now.
typically, 5 or 10 blocks is enough for that.
typically, compiler stuff is fully redistributable.
typically, over 25,000 btc.
ubuntu is the most popular distro, so i'm staying with that.
ubuntu minimize,maximize,close buttons to the right: gconf-editor apps->metacity->general button_layout=menu:minimize,maximize,close they've got it awfully buried considering 9 out of 10 users are used to having it on the right.
ui.cpp and uibase.cpp aren't linked by bitcoind.
ui.h provides inline stubs if wxuse_gui=0.
ultimately if i can't find the root of the problem, i'll have to make some kind of mechanism to watch for an absence of messages and disconnect.
ultimately, it's better to rate limit it than to let it all drain out.
un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks.
understand what tor does and does not do for you."
unfortunately there currently isn't a -dev deb package of either of the versions of wxwidgets that we can use.
unfortunately, ecdsa can only sign signatures, it can't encrypt messages, and we need the small size of ecdsa.
unfortunately, i can't receive incoming connections from where i am, which has made things more difficult.
unfortunately, proof of work is the only solution i've found to make p2p e-cash work without a trusted third party.
unless i'm missing something, i am closing the socket before exit, so i don't know what else i can do.
unless it's a touted feature of the i5 that they made sse2 six times faster.
unlimited for 24 hours they know what the cost will be.
until it finishes the orderly shutdown in the background, the port would be locked, and this is an important protection to make sure another copy can't touch the database until it's done.
until now, no scarce commodity that can be traded over a communications channel without a trusted third party has been available.
until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this!
update: the json-rpc http authentication feature in 0.3.3 solves this problem.
updated bitcoin.po attachment for 0.3.1 it does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.
updated headers.h on svn.
updated svn.
uploaded some ui changes to svn as version 0.2.5. instead of view->show generated, we now have tabs: makes it a lot easier to flip to received and check for payments.
uploaded to svn as rev 110.
use the "-4way" switch to enable it and check if it's faster for you.
use the switch "-4way" to turn it on.
use this!
users can see progress going on, see that it's improving and supported and not abandonware.
users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles.
users hold the crypto keys to their own money and transact directly with each other, with the help of the p2p network to check for double-spending.
users shouldn't have to download all of both to use one or the other.
users will depend on that to check if the pool operator is cheating them.
using a lot of cpu power to do the brute force attack discussed in the paper in addition to the above scam would not increase the thief's chances very much.
using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used.
using it in rpc.cpp may still turn out to be a mistake.
using listtransactions, it would be very easy to count both.
using multiple copies of wallet.dat is not recommended or supported, in fact all of bitcoin is designed to defeat that.
usually if it deadlocks, either the ui will stop repainting, or it'll stop using cpu even though it still says generating.
usually when there's an exception or other problem, it only stops the affected thread and everything else keeps running.
v0.2 nodes will take free transactions until the block size is over 200k, with priority given to smaller transactions.
values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000.  there's plenty of granularity if typical prices become small.
vekja.net is an example of a site like this.
version 0.1.3 exe attached.
version 0.1.5 is now available.
version 0.1.5: backup the whole %appdata%\bitcoin directory.
version 0.2 is better/faster at the initial block download.
version 0.2.6 on svn can now run as a daemon and be controlled by command line or json-rpc.
version 0.2.7 on svn.
version 0.2: you can backup just wallet.dat.
version 0.3.10 patches the block 74638 overflow bug.
version 0.3.11 is now available.
version 0.3.12 is now available.
version 0.3.13 is now available.
version 0.3.13.2 (svn rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent.
version 0.3.14 is now available svn rev 163 (ver 0.3.13.3) has the key pool feature.
version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack.
version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.
version 0.3.15 is now available.
version 0.3.17 is now available.
version 0.3.18 is now available.
version 0.3.8 adds an important security improvement.
version 0.3.8.1 is on sourceforge with the 64-bit binary updated.
versions on svn since 0.2.4 already have a "new..." button next to the address bar to encourage changing it manually too.
very much not.
very slightly.
wait for 0.3.6, i'm building it now.
was it included by the os, or did you have to build it?
was it steadily slow, or just slow down at one point?
was that on the test network?
was that the only thing i broke in the osx build?!
was the machine disconnected from the net?
was there a vista/uac security problem?
we already use boost::filesystem in a dozen places.
we also must finish upgrading to wxwidgets-2.9.0 to get utf-8 support.
we are utf-8 on all platforms including windows.
we assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed.
we can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]: p = probability an honest node finds the next block q = probability the attacker finds the next block qz = probability the attacker will ever catch up from z blocks behind given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.
we can decide to increase it when the time comes.
we can figure out the best way to do this much later.
we can look into getting a certificate later when things have settled down.
we can phase in a change later if we get closer to needing it.
we can probably establish a paragraph there.
we can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances.
we can try to use words to help the situation until code gets there.
we can use more features if we want later.
we can't safely do op_blocknumber.
we cannot compile with utf-16.
we checkpoint every 500 blocks.
we consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.
we could add a note on the registration page that if you want ssl, you can change http to https at any time and approve the self-signed certificate, or a link that does it, and the tor page can mention it too.
we could potentially schedule a far in future block when bitcoin would upgrade to a modernised arrangement with the merkle tree on top, if we care enough about saving a few bytes.
we could read lines ourselves and feed them into a map<string, string> mapconfig.
we could reset it every second whenever the time changes if we wanted.
we could take irc out at some point if we want, but i'd rather ease into it and just test our own seed system as a backup for now, and i really like the complementary redundant attributes of the two different systems.
we could use a 3rd vote to get a better idea of what we're dealing with here.
we define an electronic coin as a chain of digital signatures.
we definitely have similar interests!
we didn't have time to implement the "start bitcoin on system startup" feature on linux in time for 0.2 so it's greyed out.
we do still use a few things like wxgettranslation and wxmutex.
we don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes.
we don't have to worry about a chain of custody of communication.
we don't need to bother with a 64-bit version for windows.
we don't really need pre-compiled header.
we don't support msvc6 anymore because we use something in boost that doesn't.
we don't want to give anyone any ideas.
we don't want to lead with "anonymous".
we don't want to overstay our welcome.
we don't want to reflect badly on the reliability of the network if it throws off some malformed crud we hadn't thought to check for yet, or discovers something else anti-social to do on the network.
we fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted.
we had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour.
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.
we had this feature disabled on linux before, but then it seemed better to have the imperfect ui than to lose the feature entirely.
we have a shortage of nodes that can accept incoming connections.
we have our first language.
we have the standard icon sizes, and the full size scales nicely to anything else.
we have to trust them with our privacy, trust them not to let identity thieves drain our accounts.
we just need to spread the word and keep getting more people interested.
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.
we merely adjudicate which one of the spends is valid.
we might get a good link out of it.
we need a full blown forum software for that.
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.
we need a way for the payee to know that the previous owners did not sign any earlier transactions.
we need an application to bootstrap it.
we need direct control over sockets, it wouldn't be a good idea to get behind an abstraction layer.
we need either the ansi (libwxgtk2.8-ansi-dev) version or the utf-8 (wxwidgets 2.9.0) version.
we need enough of us so that at least one node you connect to will be 0.3.10.  the problem will start to go away when we make up more than 1/8th of the network.
we need more details about what happened madhatter.
we need this because it's only faster on certain newer cpus that have 128-bit sse2 and not ones with 64-bit sse2.
we need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed.
we need to cause a reorg, which will disconnect the invalid chain.
we need to do a continuity transition with bitcoin.org so the search engines don't think this is a new site and reset the site start date and pr data.
we need to emphasize the importance to people of setting up port forwarding on their router.
we need to know about the different models of amd or other less common cpus.
we need to replace the current bitcoin.org site with a user-oriented site before the release.
we need to stop that right away before it gets used for something bad.
we need to understand this problem better.
we now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction.
we only have four functions that interface from the node to the ui.
we only needed irc because nobody had a static ip.
we probably got spam blocked because we were allowing registrations without e-mail verification.
we propose a solution to the double-spending problem using a peer-to-peer network.
we quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4gb, that doesn't mean we're going to run out again with 64-bit anytime soon.
we really just need one block letting them through to clear up the previous transactions.
we require boost for json and a dozen things replacing dependencies on wxwidgets.
we should grey them out in the next version.
we should have a gentleman's agreement to postpone the gpu arms race as long as we can for the good of the network.
we should have a paragraph on the bitcoin.sourceforge.net homepage urging people to set up port forwarding to accept incoming connections, and a link to a site that describes how to do it for each router.
we should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.
we shouldn't delay forever until every possible feature is done.
we shouldn't upgrade to 2.0.  i made a ton of customisations that wouldn't be compatible, and i kind of prefer the look of 1.1 over 2.0 anyway.
we started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending.
we still have some more changes to make first.
we switched from ansi in 0.2 to utf-8 in version 0.3, so it must be related to that.
we use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.
we use either ansi wxwidgets 2.8, or wxwidgets 2.9.  so you still have to get it and build it yourself.
we use strong encryption, while banks still let anyone who has your account info draw money from your account.
we want to avoid windows api calls whenever possible.
we want to have a good relationship with them.
we were previously using 2.8 ansi in anticipation of getting to utf-8 without going through utf-16 hell.
we will probably need to re-do a branch around the current one, and the less you generate the faster that will be.
we will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
we'd have to make sure the send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.
we'll disable it now, and if anyone figures out how to fix it, we can re-enable it then.
we'll need to tell people to install the gtk libraries.
we'll shared-link openssl, i'm pretty sure it's always preinstalled on linux.
we're in for another big step up in difficulty at the next adjustment in about 5 days.
we're kind of in a jam here.
we're managing pretty well just using the forum.
we're moving towards 2.9.0. i know you said you didn't want vm, but as a last resort, last i checked the windows version runs fine in wine.
we're not "on the lookout" for double spends to sound the alarm and catch the cheater.
we're relying on the fact that we hardly use wx in this mode.
we're so far from reaching the threshold, we don't need that yet.
we're still in great need of sample code showing the recommended way to use the json-rpc functions, like for a basic account system on a typical storefront website.
we're the type of project they like; they've helped the tor project and done a lot to protect p2p file sharing.
we're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
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.
we've already generated 14 blocks since 74638.  the builds of 0.3.10 were uploaded about 2 and 3 hours ago.
we've always said free transactions may be processed more slowly.
we've been using the ansi version of wxwidgets 2.8.9 in anticipation of wxwidgets utf-8 support.
we've been working hard on improvements for the next version release.
web apps or anything automated will normally use json-rpc directly, not command line.
welcome to the new bitcoin forum!
welcome, harry.
well anyway, your way is safer.
well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
well, that's a relief if you build the dependencies, let me know how that goes.
were you sending by ip or by bitcoin address?
what "configure" options did you use?
what about the transaction fees for the transaction fee's transaction?
what are we doing for captcha now?
what block number is it?
what cpu is that?
what do you see as the benefits of switching the wiki?
what do you think of the zetaboards option?
what do you think, is this the right thing to do?
what do you think, should i go ahead with adding the seeds?
what do you think?
what does everyone think, should we make the switch for 0.3?
what else changes?
what happens if you send bitcoins to an ip address that has multiple clients connected through network address translation (nat)?
what hardware is that?
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?
what is "120dpi mode"?
what is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.
what is the advantage?
what is the most popular and common settings file format?
what language is your computer set to?
what operating system are you using?
what operating system?
what options did you use on the wxwidgets "configure" script?
what os are you using?
what os?
what rate are you thinking of?
what rate of not-accepted did you see?
what should it be named?
what test version were you running?
what the merchant can do is broadcast his transaction and then monitor the network for any double-spend copies.
what the op described is called "cornering the market".
what they need most is confidence they can convert it to fiat currency.
what to have displayed in the transaction list?
what version is the one where this happened?
what version of glibcxx does your system have?
what was the problem with the shortcut in the startup folder?
what was this wallet used with?
what we need most right now is website writing.
what windows version/browser doesn't font anti-aliasing work on?
what would be nice about sending by domain is you could visually verify who it's going to.
what you can currently do is set "minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized.
what's new: - command line and json-rpc control - includes a daemon version without gui - transaction filter tabs - 20% faster hashing - hashmeter performance display - mac os x version (thanks to laszlo) - german, dutch and italian translations (thanks to datawraith, xunie and joozero) get it at www.bitcoin.org, and read the forum to find out more.
what's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?
what's the simplest portable way to copy a file?
whatever size micropayments you need will eventually be practical.
when a user is logged in to their account, you show the bitcoin address they can send to to add funds.
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.
when and how fast did memory usage increase?
when any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain.
when generate is scanning hashes, it only hashes the header of the block, which is constant size.
when generating the new address, there can be an option to add an entry to the address book associated with the address, so the received transaction will be labelled.
when i designed bitcoin, i designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement.
when i eventually implement client-only mode, that won't matter much anymore.
when i left off, i was thinking about bolting a payment mechanism onto a free upload server software as an example.
when i looked at the 3.4.5 compiled sha disassembly, i couldn't see any room for improvement at all.
when i see whatever.sourceforge.net in a google search, i assume that's the official site.
when i was looking for the best sha-256 code, there was a lot of hand tuned highly optimized sha1 code available, but not so much for sha-256 yet.
when i wrote it more than 2 years ago, there were screaming hot sha1 implementations but minimal attention to sha256.
when it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends.
when sending by ip, you still send to a bitcoin address, but your computer connects to that ip, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.
when someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes.
when the incentive subsidy eventually tapers off, it may be necessary to put a market-determined transaction fee on your transactions to make sure nodes process them promptly.
when the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest.
when the miner says it found something, a while later a few coins show up in their account.
when the paper says that it means for the software to do it, and it does.
when the program runs, it looks in the directory of the exe for the file: locale\<langcode>\lc_messages\bitcoin.mo <langcode> is the two letter code of the language your os is set to, like "de" or "nl".
when the theme is more settled, i'll think about a matching logo.
when the user spends money, you increase debit.
when there are enough static ip nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.
when there is an error, the error member is now an object not a string.
when there's enough scale, maybe there can be an exchange site that doesn't do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.
when they solve the proof-of-work, they broadcast the block to everyone and the block is added to the timechain.
when using proxy port 9050, it will only make one attempt to connect to irc, then give up, since it knows it will probably always fail because irc servers ban all the tor exit nodes.
when we do implement listtransactions, maybe one way to fight that is to make it all text.
when we switched to crypto++ 5.6.0 sha-256 in version 0.3.6, generation got broken on the linux 64-bit build.
when we're near the cutoff block number, i can put an alert to old versions to make sure they know they have to upgrade.
when you add a link, you must first find the current end of the chain.
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.
when you claim a bitcoin address transaction, you give your public key that matches the hash, then you must sign it with that key.
when you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.
when you copied the directory except log.0000000002, that's the best solution.
when you exited and restarted, it connected and downloaded 45 blocks that the network found in your absence.
when you found a block, you couldn't broadcast it to the network, so it didn't get into the chain.
when you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes).
when you haven't had it running for a while, once you're connected it spins up rapidly as it downloads what was generated while you were gone to catch up.
when you make a transaction or new block, it immediately broadcasts it to the network.
when you pay for something up front, you can't get it back either.
when you posted your patch, i realized it should have been done that way instead of "-?".
when you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm.
when you send to an ip address, the transaction is still written to a bitcoin address.
when you sent 49.99, did it prompt you to pay a 0.01 fee?
when you switch from one thing to another, it has to page it in from disk.
when you take someone's block chain download, you don't want it right up to the end.
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.
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?
when you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid.
when you've used up your 1000 pages, you pay for another 1000 pages.
when your double-spend gets into a block, the first spend becomes invalid.
whenever i google search software questions, most of the hits are forum posts.
whenever the 32-bit nonce starts over at 1, bnextranonce gets incremented, which is an arbitrary precision integer.
where it says "# blocks" in the status column i'm changing it to say "# confirmations".
which operating system?
which version are you running?
which version of windows?
whichever one you've set your nat to forward port 8333 to will receive it.
while i don't think bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.
while it's tempting to do a linux port, once we do it we have that extra work with every release from then on.
while network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.
while the buying back would interestingly, one of the e-gold systems already has a form of self-defeating cycle leading to too many harvesters exploiting the spammers.
while the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers.
while the network is still small like it is now, if you can't receive incoming connections you're at more of a disadvantage because you can't receive block announcements as directly.
while the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.
while this system does not guarantee the parties against loss, it takes the profit out of cheating.
while you are generating bitcoins, why not also get free domain names for the if you currently generate 50 btc per week, now you could get 50 btc and some domain names too.
why is it there?
why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it?
wikileaks has kicked the hornet's nest, and the swarm is headed towards us.
will fix.
will svn it in a day or two.
will svn shortly.
will that definitely cause bsd to be defined on mac?
willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get address book labels for receiving addresses is confusing but i'm not sure what else to do.
windows aero is a good choice.
windows and linux users: if you got 0.3.5 you still need to upgrade to 0.3.6. wtf?
windows has named pipes, maybe that's the best analogue.
windows is still the largest user group.
windows nt/2000/xp/vista.
windows only for now.
windows, linux 32-bit or 64 bit?
wish i could figure out how to fix that.
with -connect it still uses irc, do you think it shouldn't get on irc when you're telling it to only connect to specific nodes with -connect?
with a bitcoin address, the user can't send an unidentified payment.
with a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations.
with a very small network though, someone might still figure it out by process of elimination.
with all this, it should be impossible not to notice as soon as it screws up.
with class 1, no changes are allowed for a year, which is a risk if we find issues with the current host and have to change ip.
with computer systems typically selling with 2gb of ram as of 2008, and moore's law predicting current growth of 1.2gb per year, storage should not be a problem even if the block headers must be kept in memory.
with e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.
with group signatures, it is possible for something to be signed but not know who signed it.
with just a minute or two delay, the chance of getting away without paying could be made much too low to scam.
with resync, you could do about the same thing by sending all the money from one wallet to the other.
with some fiddling, i was able to get his code to work in a test program, but not in bitcoin itself for some reason.
with the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.
with the popularity of bitcoin addresses instead of sending by ip, we can't give the impression it's automatically anonymous.
with the possibility of reversal, the need for trust spreads.
with the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.
with this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork.
with time, 2.9 will become a more mainline release.
within a few days, there will be plenty of gpu power that accepts and works on it.
without auto-run, we'll almost never retain nodes after an initial tryout interest.
without more details, it can't be diagnosed.
without the switch you get crypto++ asm sha-256.
without this fix, your node's communication sometimes goes dead.
workaround for the db::open/db::close "bad file descriptor" exception.
worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.
worst case, if you didn't want to keep track of incrementing it, extranonce could be 4 random bytes and the chance of wasting time from collision would be negligible.
would a donation of bitcoins help in the short term?
would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid.
would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too?
would it be clearer if the status said "x confirmations", like: each block essentially means another node has confirmed that it agrees with all transactions up to that point.
would it be ok to create it from the currently connected ips that have been static for a while?
would you be interested in answering his questions if i refer him to you?
would you be so kind to add us to the http://www.bitcoin.org/trade page?
would you consider making your software freely available so anyone could easily set one up?
writing a description for this thing for general audiences is bloody hard.
writing the block index is light work.
wrt the alert system, who cares?
wx/clipbrd.h isn't used, move it inside the #if wxuse_gui.
wxformbuilder turns the (c) symbol into utf-8 automatically.
wxstring is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile.
wxwidgets 2.9 is their first utf-8 version.
wxwidgets has __wxbase__ for "only wxbase, no gui features".
wxwidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard.
wxwidgets has wxcriticalsection stuff we can use.
wxwidgets is a good place to look for cross-platform support functions.
wxwidgets is mostly windows people, they wouldn't know much about gtk.
wxwidgets is pathologically single-threaded.
wxwidgets really pays off for cross platform.
wxwidgets uses the gettext standard.
xml-rpc is a bit fat.
yaml is massive.
yeah, acutely aware that i should have stayed on 9.04 or 9.10.  it's a lot more work to downgrade than upgrade and i've been squeezed for time.
yeah, i put back your startup folder shortcut code and it started fine for me too on xp and vista.
yeah, that actually is what it is.
yeah, we can phase out irc when there are enough static nodes to preprogram a seed list.
yes a bug.
yes, 0.3.7 has it.
yes, about 20 hours.
yes, i think that would be really good so each dev doesn't have to figure it out themselves.
yes, i worked out the sourceforge login problem, it was some tricky thing on the login page that exposed a quirky bug in a browser add-in.
yes, it's a technical limitation.
yes, like this.
yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.
yes, the original is 546x531 pixels.
yes, there will be natural deflation due to payment mistakes and lost data.
yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.
you also need it to receive payments by ip address.
you are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it.
you are trusting someone if you use a copy of their blk files.
you can always delete blk*.dat if it gets screwed up and let it re-download.
you can change addresses as often as you want using options->change your address.
you can create multiple addresses and give a different address to each person and label them to help figure out who's sending address, either under the address book button or the "change..." it doesn't know any names other than what you tell it.
you can create whatever you want on bitcoin.sourceforge.net.
you can delete debug.log occasionally if you don't want to take the disk space.
you can delete it when you've got it.
you can freely change their address without worrying about tracking all their old addresses.
you can get a share of them just by installing the software and contributing your idle cpu time.
you can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup.
you can get coins by getting someone to send you some, or turn on options->generate coins to run a node and generate blocks.
you can get that problem on windows if the "unicode" (meaning wchar) build is used, so that wxstring is wchar and std::string is char.
you can help ensure your transactions go through quickly by adding -paytxfee=0.01.
you can just upgrade and it'll reorg away the bad block chain.
you can locate the data directory where you want with the "-datadir=<directory>" switch.
you can move or backup your wallet file, but it needs to have only one "lineage" and only used in one place at a time.
you can only set up your nat to port-forward to one of the computers.
you can probably just comment out the line let me know if it works, and watch if it memory leaks.
you can restore just wallet.dat and it'll re-download the rest.
you can run the 32-bit version on 64-bit linux by installing ia32-libs.
you can send to my bitcoin address if you want to, but you won't get to see the full transfer sequence: 1nswywa5dvuyw89sfs3olpvlidngf48cpd you could always findstr /c:"version message" debug.log and send a test to some random person you're connected to near the end of the list.
you can shut down your node in the meantime.
you can still send it for a fee of #, which goes to the nodes that process your transaction and helps to support the network.
you can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a scanhash_ function, like scanhash(pmidstate, pdata + 64, phash1, nhashesdone).
you can tell this is happening when your blocks are numbered sequentially, without other people's blocks interspersed, like: it's implausible that you would be the only one to find blocks for 6 blocks in a row like that.
you can try moving addr.dat aside.
you can use -connect to make it connect to local computers on your lan, like -connect=192.168.0.100.
you can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it?
you can't have the genesis block.
you can't use a birthday attack for this, so the difficulty is the full 2^160 bits.
you confirmed when you shut off generation that your cpu drops to 0%, so the cpu usage is definitely all idle priority.
you could always exchange for liberty reserve.
you could always set a minimum order size to keep orders more infrequent.
you could comment out the createthreads listed below, then re-enable them one at a time until it does it again.
you could delete the locale directory that came with bitcoin so it doesn't try to use it.
you could have got a lot more money by generating blocks.
you could sell it back to spammers who don't have big enough botnets to generate their own, helping bootstrap the currency's value.
you could still prove your total power at given times without running it all the time.
you could test by timing an initial block download with and without db_private, preferably -connect-ing to a local machine so network isn't a factor.
you could try building for that instead of __wxgtk__ and see what happens.
you could use tor if you don't want anyone to know you're even using bitcoin.
you could use tor to mask that.
you create an account on a website and hold your bitcoins on account there and transfer in and out.
you did some research when choosing hosting, this was a well chosen one, right?
you do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms.
you don't connect directly with them and they don't have to be online at the time.
you don't have a single private key that unlocks everything.
you don't have to be online during that time.
you don't make progress towards solving it.
you don't need to be re-broadcasting your transactions for it to work.
you don't need to update to 0.3.1 unless you had one of the problems listed in the first post.
you don't realise the problems with an api until you actually try to use it.
you found an infrequent bug in createtransaction.
you got a lot done with the linux build, autostart, minimize to tray, setup and everything, it's really appreciated.
you had no communication with the network, but because you had 8 zombie connections, it thought it was still online and kept generating blocks.
you have connections, which tricks bitcoin into thinking it's connected, but they are silent because the data is being blocked.
you have one piece of work.
you have the option to release it at any time forever.
you have to be careful not to break or continue out of it.
you have to widen up the comment column to see them.
you know long before that that you won one.
you know, i think there were a lot more people interested in the 90's, but after more than a decade of failed trusted third party based systems (digicash, etc), they see it as a lost cause.
you may get ideas from things other users come up with and try.
you may need to upgrade."
you may see the block count pause at ?
you might consider a certain amount of work to generate a domain, instead of a fixed total circulation.
you might find it preferable not to translate it into your own language.
you might not want to use this for a website server until it's had some more testing.
you need to keep a "debit" amount in your database.
you need to make bitcoin.exe an excluded process in live protection.
you now have access.
you only need to keep the latest bitcoin address for the account in your database.
you pay for, say, 1000 pages or images or downloads or searches or whatever at a time.
you probably developed these rituals of transferring to a fresh install to cope with database corruption.
you really don't want to keep running in wine, you're getting database errors (db.log).
you run gdb bitcoin.exe then type "run" then if it crashes, type "backtrace" for a stack dump, or it may do it automatically.
you said your friend was getting 1400-1600 khash/s, so it was getting cpu.
you see the first spend, you count it.
you see the second spend, you count it.
you send the transaction to the network the same way you relay transactions.
you should be good now.
you should never delete a wallet.
you should not use polipo or privoxy as those are http filters and caches that would corrupt bitcoin's messages if they make any changes.
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.
you should probably change the part about "distribute them under several keys".
you should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.
you should restart it.
you should run with the "-debug" switch to get some additional debug.log information i added that'll help if there are more problems.
you should try it with tcatm's 4-way sse2 sha in sha256.cpp.
you should upgrade to prevent potential problems with 0/unconfirmed transactions.
you should use at least some priority in case a flood comes along before the next block.
you should use port 9050. as rix says, the "is giving tor only an ip address.
you shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.
you simply cannot count on users to enter the right thing in the comment fields to identify the transaction.
you still have to get sha-256 to output that value, so you would still have to break sha-256 too.
you still must trust the supplier of the zipfile.
you use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file.
you were looking at the wrong code.
you weren't receiving anything either to know that the network had gone on without you, until you restarted it.
you would be certain you're connected to who you thought, and safely encrypted.
you would count both spends.
you would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.
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.
you would usually know whether you're in the smaller segment.
you write a payment that requires the signature of both the recipient and the sender to spend it.
you write it with the same inputs and outputs, but this time with a fee.
you wrote some code before so you should be there.
you'd still have to press send.
you'd think as long as it doesn't actually execute any sse2 instructions, it would still load.
you'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
you'll want one that's old enough that it ends block 74000 so the most recent security lockin will check it.
you're also confusing me, what do you mean?
you're blindly sending to whoever answers that ip.
you're probably right, it's about time to do a linux build.
you're right about the minimize on close option, there's no reason that can't be separate.
you're right, i was looking at a test run with 250,000 blocks... duh.
you're right, sorry about that.
you're right, that was it.
you're the best person to do it.
you're using python, right?
you've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility.
you've handed control of the money over to the recipient's keypair.
your addresses are referred to as "receiving addresses".
your balance would have been lower than the amount.
your block will never become valid because nobody received it.
your faq looks good so far!
your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.
your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours.
your node receiving incoming connections was the main thing keeping the network going the first day or two.
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.
your transaction is essentially "in" that many blocks.
your transactions and generated blocks show as 0/unconfirmed until it's done downloading.
zetaboards pros and cons: pros: - we don't have to worry about bandwidth - they handle the backend management and security patches con: - lack of ssl - lack of privacy, everything is logged - lack of control over the php code for customization - no captcha, and if they add one later it might be unacceptable flash - ads (could pay to get rid of them later if we care enough) - there's always the risk they abruptly cancel the site for some petty reason test 7: backup your data directory before running this, just in case.