| 00:01 | Keefe | anyone have a webpage listing all the diff adjusts so far? or should i just dig thru my logs? |
| 00:01 | gavinandresen | I saw a graph of difficulty over time somewhere, but can't remember where. |
| 00:03 | gavinandresen | Keefe: http://nullvoid.org/bitcoin/difficultiez.php |
| 00:04 | necrodearia | gavinandresen, nice graph ^_^ |
| 00:04 | gavinandresen | Gotta love ASCII graphics :) |
| 00:05 | Keefe | perfect! |
| 00:05 | gavinandresen | (makes me pine for the good old days back in May when the difficulty was 11 and I first heard about bitcoin....) |
| 00:29 | echelon | ok, let me ask again |
| 00:29 | echelon | if i want to remain anonymous and run bitcoin behind tor, i shouldn't open a port for bitcoin, right? |
| 00:37 | echelon | a_meteorite, AAA_awright? |
| 00:38 | AAA_awright | Why would you want to do that? |
| 00:38 | AAA_awright | Why are you pinging me? |
| 00:38 | AAA_awright | As if I would know? |
| 00:38 | AAA_awright | echelon: Bitcoin is anonymous |
| 00:38 | echelon | no it isn't! |
| 00:38 | AAA_awright | It doesn't serve any data, it just propagates it |
| 00:39 | echelon | all transactions can be tracked back to its origin |
| 00:39 | AAA_awright | Tor isn't going to fix that |
| 00:42 | echelon | why |
| 00:42 | AAA_awright | It's not going to change your Bitcoin address...? |
| 00:46 | doublec | echelon, have you read the page on the bitcoin site about anonymity? |
| 00:48 | doublec | echelon, this covers it: http://www.bitcoin.org/smf/index.php?topic=241.0 |
| 00:48 | bitbot | Anonymity |
| 00:52 | a_meteorite | echelon |
| 00:52 | echelon | yeah |
| 00:54 | a_meteorite | you pinged me, so back at ya |
| 00:54 | echelon | oh, sorry :) |
| 01:01 | Keefe | generation rate since the last diff adjust doesn't look so unusual now that more time has gone by |
| 01:02 | Keefe | i'm putting together a chart for total power averaged over 48-block (8 hrs at target rate) ranges |
| 01:02 | Keefe | will give you guys a link when done |
| 01:40 | kaja | hello. i want to translate the bitcoin and bitcoind do esperanto. How do I do that? |
| 01:40 | nanotube | kaja: mmm... grab the source, and start translating...? :) |
| 01:40 | kaja | but that's stupid because then there would be binaries for every language..? |
| 01:41 | kaja | also i'm just running the command 'bitcoind' and i'm not generating any coins.. is that because i need the -gen flag? |
| 01:41 | nanotube | kaja: indeed... i'm not sure whether any work has been done for bitcoin internationalization... ideally it would use some nice library and pull translated strings out of .po files or something... |
| 01:42 | nanotube | yes if you don't add the -gen, it won't generate |
| 01:42 | kaja | no wonder! damnit |
| 01:42 | kaja | i could have had probably 2 coins by now :( |
| 01:42 | Keefe | how long have you been trying? |
| 01:42 | kaja | a day and a half |
| 01:42 | nanotube | kaja: and what's your generation rate? |
| 01:43 | kaja | how do I find that out? |
| 01:43 | Keefe | do you have an average cpu? |
| 01:43 | nanotube | there's a bitcoind command to do that... but i forget what it is. |
| 01:43 | Keefe | even the best cpu's don't generate more than about a block a month now |
| 01:43 | Keefe | bitcoind getinfo |
| 01:43 | Keefe | nevermind |
| 01:44 | kaja | what's a block a month mean? How many coins is that? |
| 01:44 | Keefe | 50 |
| 01:44 | nanotube | aha, command is gethashespersec |
| 01:44 | Keefe | you can't generate just 1 btc |
| 01:44 | kaja | ah |
| 01:44 | nanotube | try running bitcoind gethashespersec and see what it says |
| 01:44 | kaja | so after a couple of months i'll suddenly get 50btc? |
| 01:45 | Keefe | maybe |
| 01:45 | Keefe | maybe today, maybe next year |
| 01:45 | kaja | kiah ~ > bitcoind gethashespersec |
| 01:45 | nanotube | kaja: are you running a bitcoind -daemon ? |
| 01:45 | kaja | ah |
| 01:45 | kaja | kiah ~ > bitcoind -daemon gethashespersec |
| 01:45 | kaja | 0 |
| 01:45 | kaja | hehe |
| 01:46 | kaja | kiah ~ > bitcoind -daemon gethashespersec |
| 01:46 | kaja | there |
| 01:46 | Keefe | ;khash 421 |
| 01:46 | bitbot | Keefe: ProbabilityPerSecond(0.00000007433373562316530531567205) Chances: Avg(155d 16:54:01) 25%(44d 19:02:21) 50%(107d 22:13:19) 75%(215d 20:26:38) 95%(466d 10:45:12) 99%(717d 1:03:46) |
| 01:46 | nanotube | ah... so 421khs... |
| 01:46 | kaja | i didn't understand that at all |
| 01:46 | nanotube | so... prepare to wait on average ~107 days to generate a block... |
| 01:46 | Keefe | run it for a year and you probably will get a couple blocks |
| 01:46 | kaja | yay |
| 01:46 | nanotube | Keefe: (assuming difficulty doesn't go up... which it will....) |
| 01:47 | Keefe | was about to say |
| 01:47 | nanotube | heh |
| 01:47 | Keefe | i wouldn't be surprised if diff is 10 times higher in a few months |
| 01:48 | Keefe | it's quite unfortunate for the little guys hoping to get a few coins with just processing power |
| 01:48 | kaja | i've seen a couple of people uploading .po files |
| 01:48 | kaja | for french, spanish and portuguese |
| 01:48 | Keefe | but it's good for the system |
| 01:48 | kaja | but you guys say i must edit the source code...? |
| 01:48 | Keefe | i know nothing about that stuff myself |
| 01:48 | kaja | well i sent emails to every online esperanto shop i could think of |
| 01:49 | nanotube | kaja: i haven't really looked at the bitcoin source myself... it's possible that it already does use the .po files |
| 01:49 | kaja | so now i am trying to get everything translated in esperanto very quickly |
| 01:50 | kaja | well i don't know where to get the english.po so that i can translate it |
| 01:52 | Keefe | stick around here. i'm sure there are a few that do know what you need to do |
| 01:53 | kaja | ok |
| 02:08 | echelon | bitcoin exists at startup when i add -server parameter |
| 02:09 | echelon | ooh.. sorry nvm |
| 02:14 | echelon | weird.. port scanning bitcoin on 8332 with nmap makes bitcoin quit |
| 02:15 | nanotube | echelon: hrm... could be a possible dos vector? |
| 02:15 | nanotube | maybe you should report that |
| 02:15 | echelon | hrm.. it's not happening anymore |
| 02:16 | nanotube | mmm |
| 02:18 | kaja | how do i find the exchange rate of bitcoin to AUD |
| 02:18 | kaja | australian dollar |
| 02:18 | kaja | i'm selling an item on biddingpond :) |
| 02:19 | Keefe | anyone know the exact block count right when that slashdot story was posted? |
| 02:20 | Keefe | http://news.slashdot.org/story/10/07/11/1747245/ |
| 02:20 | nanotube | kaja: well, you can look up the exchange rate between bitcoin and usd, on say... mtgox or bitcoinmarket... and then convert to AUD using the current usd-aud exchange rate |
| 02:20 | Keefe | on my pc it says it was posted July 11, @05:09PM |
| 02:20 | Keefe | not sure whether it uses my time zone (us pacific) or not |
| 02:21 | kaja | why does 0.05 in bitcoin actually mean i have 5BTC? |
| 02:21 | kaja | what's with the decimal point |
| 02:22 | Keefe | 0.05 is not 5 |
| 02:22 | kaja | ah |
| 02:22 | kaja | hm |
| 02:22 | Keefe | i'm guessing you got the 0.05 from the "faucet"? |
| 02:23 | Keefe | i think they used to give out 5btc each |
| 02:23 | Keefe | now just 0.05 |
| 02:23 | doublec | 5 btc is 5 bitcoins. 0.05 bitcoins is 0.05 btc |
| 02:23 | doublec | they give out 0.05 if their balance is below $500 otherwise it's 0.50 |
| 02:26 | kaja | Keefe: ah |
| 02:26 | kaja | http://www.biddingpond.com/item.php?id=75 my first listing :) |
| 02:40 | Keefe | http://oi55.tinypic.com/34iqmc7.jpg |
| 02:41 | Keefe | ^ chart of total bitcoin processing power since about a week before /. |
| 02:41 | Keefe | 48-block averages |
| 02:41 | Keefe | measured in estimated mhps |
| 02:42 | Keefe | the tiny ticks below the x axis represent diff adjusts |
| 02:42 | nanotube | Keefe: wow, nice. looks like the /.ing really helped as far as generating a critical mass of public interest. |
| 02:43 | Keefe | so that chart covers about the last 3 months |
| 02:48 | smop | is there a bitcoin converter? |
| 02:48 | Keefe | exchange? |
| 02:49 | Keefe | mtgox.com and bitcoinmarket.com are popular ones for exchanging btc <-> usd |
| 03:20 | kaja | the esperanto community will bring bitcoin to critical mass! just you wait |
| 03:21 | kaja | i'm gonna embark on some super heavy campaigning |
| 03:29 | LobsterMan | esperanto..... |
| 03:29 | LobsterMan | welcome to 1971? |
| 03:31 | smop | kaja: lol |
| 03:32 | LobsterMan | so im trying to build bitcoin on windows...ive already built wxwidgets/openssl/db/boost.....where do i want to put the static libraries and stuff that it generated with respect to the makefiles so that i can try to compile bitcoin? |
| 03:39 | LobsterMan | ...anyone? |
| 03:39 | LobsterMan | <_< |
| 03:56 | kaja | LobsterMan: 1971? What has that got to do with anything? |
| 04:04 | LobsterMan | ^_^ |
| 04:04 | kaja | LobsterMan: heh, sorry that i can't answer your question |
| 04:04 | LobsterMan | :P |
| 04:05 | kaja | anyway so i was just kind of kidding that esperanto will bring bitcoins to critical mass |
| 04:05 | LobsterMan | i know |
| 04:05 | LobsterMan | lol |
| 04:05 | kaja | hehe |
| 04:05 | kaja | but it can't hurt to send emails to a bunch of online esperanto shops asking them to accept bitcoins as payment and translate the documentation to esperanto |
| 04:05 | kaja | every little bit helps |
| 04:05 | LobsterMan | ..go for it |
| 04:05 | LobsterMan | :P |
| 04:06 | kaja | i already am! |
| 04:09 | LobsterMan | http://www.imdb.com/title/tt0368667/ |
| 04:09 | LobsterMan | err |
| 04:09 | LobsterMan | wrong chan |
| 04:47 | thrashaholic | is there no seperate source for wxGTK-2.9? does it come bundled with regular wxWidgets--2.9.1 now or something? |
| 04:49 | thrashaholic | i'm trying to build gavin's github master, it's trying to link wxgtkud-2.9 and all i can find/have is 2.8 :/ |
| 04:53 | thrashaholic | n/m i see, that'd be a yes =) |
| 04:54 | echelon | is there a way to remove individual transactions? |
| 05:28 | lfm | echelon, what you mean remove transactions? |
| 05:39 | lfm | some fool is donating 5 bitcents at a time to the faucet for like 100s of transactions! |
| 05:44 | kaja | lfm: hahaha |
| 06:01 | echelon | lfm, remove old transactions that you've already spent |
| 06:03 | Tritonio | how do you remove transactions from the list? |
| 06:03 | echelon | that's what i'm asking |
| 06:04 | Tritonio | and btw is there a way to remove receiving addresses? not remove them, that would be dangerous. just hide them. is it possible? |
| 06:04 | lfm | I dont think they ever go away |
| 06:04 | echelon | so if you're at 0.00 balance, just delete wallet.dat? |
| 06:04 | lfm | ya, start a new wallet and send everything to it |
| 06:05 | echelon | ok |
| 06:05 | eureka^ | i know this is off topic, just asking everywhere i can. has anybody seen this before? http://s11.info/~solar/intense_excitement.jpg |
| 06:06 | lfm | eureka^, what is it, just an uglly jpeg |
| 06:06 | eureka^ | a fridge magnet i'm trying to find the source of |
| 06:07 | Diablo-D3 | huh, dunno |
| 06:07 | echelon | wait, how do you send bitcoins from your old wallet to a new wallet? |
| 06:07 | lfm | create the new wallet, note the address for the new wallet, go back to the old one and send coins to the address |
| 06:09 | lfm | no problem! |
| 06:10 | lfm | if you screw up you lose all your coins of course |
| 06:11 | lfm | delete the wrong wallet or copy the wrong direction |
| 06:11 | doublec | another approach is sign up to something like mybitcoin.com and send all your money there. Then at least you won't delete the wrong wallet. |
| 06:11 | echelon | ah cool |
| 06:12 | lfm | why would people use http://bitcoin2cash.com/ their prices are terrible! |
| 06:13 | doublec | 25 bitcoins for $1 usd sounds ok |
| 06:13 | echelon | well.. $1 ~ 16btc |
| 06:13 | echelon | yeah |
| 06:14 | doublec | it's the other way that sucks |
| 06:14 | echelon | but that's with postage |
| 06:14 | lfm | 200BTC for $1? |
| 06:14 | echelon | so.. $1.44 for 25 btc |
| 06:15 | lfm | is $0.005 per BTC the market pays 0.06 I thot |
| 06:16 | lfm | do you see a different rate than me? |
| 06:17 | lfm | ok I had a stale page. I see now |
| 06:17 | lfm | still the 200BTC for $1 is poor |
| 06:21 | lfm | like theyre charging 400% service charge or something |
| 07:23 | Tritonio | lfm: it's just that the page is the same as when it got online. They haven't changed their rates ever i think. |
| 07:32 | kermit | well at least the hostname parts have been removed from the public logs |
| 07:44 | Tritonio | where are the logs btw? kermit? |
| 07:45 | kermit | i cant find them now, the forum about them just said the hostnames were removed, but it looks like maybe they all have been |
| 07:46 | kermit | oh i found them http://stuff.caurea.org/irssi/freenode/%23bitcoin-dev/2010/09/ |
| 07:51 | Tritonio | btw anybody knows what is going on with bitbet.org? |
| 07:52 | Tritonio | it's down for days... |
| 07:59 | kermit | i seem to have broken my wallet, nothing i send ever gets confirmed now |
| 08:36 | FreeMoney | up and then down again for me joe |
| 08:37 | joe_1 | right now? |
| 08:40 | joe_1 | The IP address changed again about 15 minutes ago because I restarted the site and installed new software to automatically redirect the URL to the correct IP address. If you have it bookmarked to an IP address it is best to change the bookmark to point to the cashcow.no-ip.org instead, so that it always takes you to the site. |
| 08:41 | FreeMoney | that works sorry |
| 08:45 | kermit | is there a way to set the port so i can run more than 1 on one machine? |
| 08:49 | joe_1 | on cashcow? |
| 08:49 | joe_1 | or bitcoin |
| 08:50 | joe_1 | i'd also like to know if that's possible |
| 08:50 | kermit | bitcoin |
| 08:51 | joe_1 | if its randomly assigned then you can probably get away with it |
| 08:51 | kermit | joe_1: did you know this http://www.bitcoin.org/smf/index.php?topic=1300.0 |
| 08:51 | bitbot | Wallet.dat backups may lose transactions prior to backup (and this is not a bug) |
| 08:52 | kermit | randomly assigned ports make p2p less reliable |
| 08:52 | joe_1 | I read it this morning |
| 08:52 | kermit | but you should still have the option |
| 08:52 | kermit | i could see you running two so you have the 'svaings' wallet that rarely sends |
| 08:52 | kermit | so its backpus stay valid |
| 08:55 | joe_1 | yeah |
| 08:57 | joe_1 | where do you normally back yours up to |
| 08:57 | joe_1 | email or a disk |
| 08:57 | kermit | my fileserver |
| 08:58 | kermit | i dont have much in it though..encrypting it and mailing it to yourself is a good idea. |
| 09:01 | joe_1 | when bitcoin exchange rate goes up to 50$, I'll back it on to a disk and have a million dollar floppy disk like on that movie hackers. |
| 09:08 | joe_1 | i think it was brought up on the forum a while ago that the software should provide greater control on exactly which previous transactions are used / broken up to satisfy a send. |
| 09:08 | joe_1 | so when I receive 1 BTC from person A, then 1 BTC from person B, and want to send 1 BTC to person C, i can choose whether it's the one from A or B. |
| 09:09 | joe_1 | this also makes it clearer to understand why the bakup of wallet.dat can lose prior transactions |
| 09:17 | Tritonio | joe_1: no you can't. and i agree you should have complete control over which wallet identity the money comes from. |
| 09:20 | joe_1 | Then a dialog should appear, with "XX bitcoins were taken from your last wallet backup to satisfy this send. Would you like to back up again now?" |
| 09:20 | kermit | joe_1: as long as it uses some good logic, as in to send the most confirmed things first |
| 09:20 | kermit | joe_1: now that would be good |
| 09:21 | joe_1 | Actually it should use the least confirmed things first, because those are most likely not in your last backup, so you're only losing money that you have gained since your backup. |
| 09:21 | kermit | joe_1: even something like 'execute .. backup command after each send' |
| 09:22 | kermit | joe_1: oh, yeah but that has its own problem.. it propogates possibly fraudulent coins faster |
| 09:24 | joe_1 | true, but as a bitcoin recipient we should always assume it is fraudulent until we get a couple confirmations anyway. just because it passed through a bunch of people really fast before it got to us doesn't mean we have to wait longer. |
| 09:32 | joe_1 | but that's a good point, if we always send the least confirmed, I may send a 0/unconfirmed to my friend, then it will get pulled back if the network rejects the original send to me. |
| 09:32 | kermit | joe_1: someone added something to the thread that i guess will help.. i dont understand enoguh to know if it would work.. but it said in the future new addresses will be generated in blocks so backups would be valid longer. |
| 09:33 | joe_1 | Yeah that would work well |
| 09:34 | kermit | does that also mean then that if you dont use a newer address, your old backup will still work? |
| 09:35 | doublec | kermit, instead of changing the port can |
| 09:35 | doublec | 't you run one instance and connect the others to it |
| 09:35 | doublec | using the -connect switch? |
| 09:36 | doublec | or is the json-rpc port your talking about? |
| 09:36 | kermit | doublec: -connect doest make it not still want port 8333 for itself too |
| 09:37 | doublec | ok, I thought it did |
| 09:37 | kermit | hmm is bitcoind just bitcoin -daemon ? |
| 09:38 | kermit | doublec: but thanks for the suggestion, it was worth a try |
| 09:38 | doublec | yes it is (bitcoin -daemon) |
| 09:39 | kermit | oh hm so i dont need to keep compiling two binaries :) |
| 09:40 | doublec | yeah I just build bitcoind |
| 09:41 | doublec | as it doesn't link in the wx libraries |
| 09:56 | UukGoblin | ;estimate |
| 09:56 | bitbot | UukGoblin: LastDiff(0d 15:55:44 ago) ExpBlocks(95) ActualBlocks(118) TrgNewDiffDate(2010/10/12 19:58:28 GMT) EstNewDiffDate(2010/10/10 04:06:55 GMT) EstNewDiff(1637.92751256) |
| 09:56 | UukGoblin | yesus. |
| 09:57 | UukGoblin | OMG! IT'S ALIVE! |
| 10:15 | Tritonio | http://www.bitcoin.org/smf/index.php?topic=1307.0 |
| 10:15 | bitbot | BTConvert |
| 11:59 | Tritonio | sooo.... |
| 11:59 | Tritonio | how many transactions fit in a block? |
| 11:59 | Tritonio | more or less? |
| 12:09 | kermit | Tritonio: i wastn able to gleen a yes/no out of your answer to nanotube's question "so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?" |
| 12:13 | Tritonio | you mean you didn't understand if I answered yes or no? |
| 12:14 | kermit | Tritonio: yes |
| 12:14 | idev | Hello i wonder if someone can help me, how would i install btc on a mac |
| 12:14 | idev | also please note im really clued up on commands and such ! |
| 12:15 | idev | not* |
| 12:15 | Tritonio | kermit: AFAIK there will be no invalid chain. You will propagate those "invalid" coins that will eventually get into the chain. Until the get into the chain it will be dangerous to use them since you don't know if they have been double spent. |
| 12:15 | kermit | Tritonio: the client will send out unconfirmed recieved coin? |
| 12:17 | Tritonio | i think yes. do you want to try it? Make a new wallet somewhere |
| 12:18 | kermit | if so, and it combines it with other coins, then the change from that send will also remain unconfirmed, so your wallet will soon end up incapable of sending transactions that will be confirmed. |
| 12:18 | Tritonio | I will send you 0.1BTC and then you will send it back immediatelly. |
| 12:18 | kermit | send me .001 |
| 12:18 | kermit | 14gKWVDXVTbGgNpdWmpqtpXwJtHuPeRJgH |
| 12:18 | Tritonio | have you got a completelly empty wallet? |
| 12:18 | kermit | yes |
| 12:18 | kermit | never used |
| 12:19 | Tritonio | btw i can't send you 0.001. I will send you 0.05. |
| 12:19 | kermit | that wont test what we've been talking about |
| 12:19 | Tritonio | it will. even if i send you 0.05 it wount get confirmed for about 10minutes. |
| 12:19 | kermit | well i guess if i do it reall y fast |
| 12:19 | kermit | ok |
| 12:19 | kermit | sure |
| 12:19 | Tritonio | so you can send it right back. |
| 12:20 | Tritonio | sent |
| 12:20 | Tritonio | send them back as soon as you get them |
| 12:20 | Tritonio | 1ACakd85b9pNh4a9a5w9cY8n7TDVVw5tSV |
| 12:20 | kermit | wow |
| 12:20 | Tritonio | got them |
| 12:21 | kermit | so i can break everyone's wallet by sending them .001btc ?? |
| 12:21 | kermit | with no txfee |
| 12:21 | Tritonio | see? it sends them even if they are unconfirmed. so if this chain of transactions has a ad beggining (like a transaction without a fee) it will be unconfirmed for a long time. |
| 12:22 | Tritonio | kermit: yes. kind of. They will be able to send money, but until your transactions get confirmed, which will take some time if you don't include the fee, they won't be able to use them. |
| 12:22 | Tritonio | I just hope the clients give priority to long confirmed coins when sending out money... |
| 12:22 | kermit | but we just showed they can use them before they're confirmed |
| 12:22 | kermit | i hope so too |
| 12:22 | Tritonio | yes they can use them but their transactions will be unconfirmed too... :-) |
| 12:23 | kermit | and it'll infect other coin because it will get combined with it in a payment, and their remaining change will be part of the chain |
| 12:23 | Tritonio | I made a mistake when saying "the won't be able to use them". I meant they won't get confirmed transactions too. |
| 12:23 | kermit | so, if i wanted to, i could pretty much take down bitcoin right now |
| 12:23 | Tritonio | Yes. |
| 12:23 | Tritonio | :-D |
| 12:23 | kermit | thath wasnt made clear in your thread comment.. |
| 12:24 | kermit | someone should be made aware |
| 12:24 | Tritonio | I still think the best solution would be to flood the netowork with 1BTC transactions going back and forth between two wallets (but different addresses) |
| 12:24 | kermit | but i could break it bi accident |
| 12:24 | Tritonio | those transactions will not need a fee and everybody will try to process them so the blocks will get full. |
| 12:24 | kermit | i sent nanotube some .0001 without fees |
| 12:24 | Tritonio | hehe good for him. :-D |
| 12:25 | kermit | and if he uses that wallet to send, and it gets combined.. and then the same thing hahppens to someoe else |
| 12:25 | kermit | that might spread |
| 12:25 | kermit | like a 'virus' |
| 12:25 | kermit | until nohting is being confirmed |
| 12:25 | kermit | becuase itll combine, then split as change, etc etc |
| 12:25 | MacRohard | kermit, only if they used the received unconfirmed money in a new transaction which probably they wouldn't? |
| 12:25 | Tritonio | we've already concluded that the protocol kinda sucks... :-) I wish I find some time to read the bitcoin code and try to fix some things... |
| 12:26 | kermit | MacRohard: why wouldn they? |
| 12:26 | MacRohard | kermit, 'cause it's unconfirmed? |
| 12:26 | kermit | MacRohard: i just used unconfirmed coin |
| 12:26 | Tritonio | MacRohard: they can't control which coins they use. We just hope the client gives priority to confirmed ones. |
| 12:26 | kermit | MacRohard: are you saying it prefers confirmed coin first and he'll only use it if its all he has to use? |
| 12:26 | MacRohard | Tritonio, right that's what i'm assuming. |
| 12:26 | MacRohard | i don't know |
| 12:27 | MacRohard | but that is my asumption |
| 12:27 | kermit | i'd like to think so too |
| 12:27 | Tritonio | MacRohard: If it does then it's almost OK. It won't "spread". Still the flooding attack can work I think. |
| 12:27 | kermit | Tritonio: why wouldnt it spread? if it got combined with some other payment, then the both the payment and the payrment's change would never confirm |
| 12:27 | kermit | so it would turn into 2 unconfirmed lots |
| 12:27 | MacRohard | Tritonio, i tried to flood a while ago.. just using a script. it didn't work - the bitcoin client just starts slowing down. I don't know why though as I didn't delve into it deeply. |
| 12:28 | Tritonio | well if it's just a client precaution you can edit te code. If it is the netowork that slows you down, you just need more nodes. |
| 12:29 | kermit | i could send .001btc with no fee to everyone connectend and find out, but that'd be kind of evil, it'd be better to get someone who knows more to consider the posisbility. |
| 12:29 | Tritonio | kermit: btw our tx just got confirmed. |
| 12:36 | Tritonio | kermit: it wouln'd spreat since if I have 50BTC and you send me 0.001, I won't have to spend them anywhere. If it prioritizes the 50BTC I would be carefull not to use more than my confirmed money. |
| 12:36 | Tritonio | spread* |
| 12:37 | kermit | if it prioritizes the 50BTC.. maybe it prioritizes consolidating the smallest lots first, to reduce overhead? |
| 12:38 | kermit | but ok even if it does prioritized the 50BTC, doesnt that simply delay the matter? |
| 12:38 | MacRohard | not really |
| 12:38 | MacRohard | it just means you can't send money if you don't have any |
| 12:38 | kermit | MacRohard: the client does unconfirmed coin by default |
| 12:39 | MacRohard | yes but that doesn't matter |
| 12:39 | MacRohard | you can send unconfirmed money, but it will be unconfirmed when the receiver gets it |
| 12:39 | kermit | and the reciver can send that too |
| 12:39 | MacRohard | sure |
| 12:39 | kermit | and have change from sending it, which also remains unconfirmed |
| 12:40 | kermit | so it multiplies |
| 12:40 | MacRohard | yeah.. so you've found a way to spam wallets |
| 12:40 | MacRohard | it doesn't realy change anything |
| 12:40 | MacRohard | the person who receives the unconfirmed moneys will go back and demand real moneys |
| 12:40 | kermit | how will they fix their wallet? |
| 12:40 | MacRohard | dunno. that might be a real problem, but it should be fixable in theroy. |
| 12:41 | kermit | if their wallet is al change from unconfirmed sends because their components were unconfirmed.. |
| 12:41 | kermit | im thinking clients shouldnt let you send unconfirmed coin, heh |
| 12:41 | MacRohard | as long as it prioritizes confirmed then there's no real problem other than you'll have a bunch of crap transactions in your wallet |
| 12:42 | kermit | i think prioritization would make the consequneces slower, but still untilmately contageous |
| 12:42 | MacRohard | it isn't contageous |
| 12:42 | MacRohard | each person has to willingly send unconfirmed coins |
| 12:42 | MacRohard | which is a pointless thing to do since the receiver will figure it out pretty soon |
| 12:42 | kermit | my GUI didnt make that clear that i was doing that |
| 12:44 | Tritonio | Kermit you lost your chance for a quick fix. You should have told us. You should have messed every address up. :-D |
| 12:44 | Tritonio | You shouldn't have told us I mean... |
| 12:44 | kermit | Tritonio: i still could :P |
| 13:02 | keith4 | did anyone publish GPU-generating code yet? |
| 13:02 | Tritonio | bye bye |
| 13:10 | UukGoblin | someone should stick info about GPU in the topic |
| 13:10 | UukGoblin | oh, I'm an op |
| 13:10 | UukGoblin | shame I don't know the answer ;-] |
| 13:20 | nanotube | keith4: UukGoblin: iirc puddinpop's code was posted on the forums |
| 13:21 | UukGoblin | as an attachment or something? |
| 13:21 | UukGoblin | could someone please make a github of it? ;-] |
| 13:21 | kermit | i saw an http link to the source, i didnt see any binary |
| 13:21 | nanotube | yes it was an attachment i think |
| 13:21 | kermit | its in the big GPU thread somewhere |
| 13:22 | keith4 | this one? http://www.bitcoin.org/smf/index.php?topic=1009.0;all |
| 13:22 | bitbot | A slightly more open approach to bitcoin on the GPU |
| 13:23 | UukGoblin | that one was an alternative version imho |
| 13:24 | UukGoblin | hmm, is there a freebsd 64-bit binary of bitcoind somewhere? :-] |
| 13:25 | kermit | UukGoblin: freebsd can run linux binaries, but youll still need the libraries or a static binary |
| 13:26 | UukGoblin | # ./bitcoind |
| 13:26 | kermit | UukGoblin: theres a 'module' or whatever bsd calls them to run linux binaries |
| 13:26 | keith4 | ah, this one. http://www.bitcoin.org/smf/index.php?topic=133.40 |
| 13:26 | bitbot | Generating Bitcoins with your video card (OpenCL/CUDA) |
| 13:29 | idev | How can i install Bitcoain on my home mac or my linux webserver please anyone? |
| 13:31 | nanotube | idev: just grab the released binaries from bitcoin.org, and run them |
| 13:31 | nanotube | nothing special to be done |
| 13:34 | idev | @ nanotube, im not sure how to run it |
| 13:34 | idev | as in the binary i downloaded there was just a buch of files and an exe, but im on a mac? |
| 13:36 | necrodearia | idev, You downloaded http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/bitcoin-0.3.11-macosx.zip/do... ? |
| 13:36 | gavinandresen | idev: you should have got a .zip file for your Mac, with a Bitcoin.app inside that you can drag to Applications |
| 13:37 | gavinandresen | idev: on linux, you should download the .tar.gz, then tar -xzf it and run "bitcoin" or "bitcoind" (depending on whether you want graphics or not) |
| 13:38 | nanotube | UukGoblin: for the cuda client... the better page to link to would be http://www.bitcoin.org/smf/index.php?topic=133.140 where the source to puddinpop's client is posted |
| 13:38 | bitbot | Generating Bitcoins with your video card (OpenCL/CUDA) |
| 13:39 | UukGoblin | nanotube, that's what I linked :-] |
| 13:39 | UukGoblin | only made it shorter with bit.ly |
| 13:39 | necrodearia | UukGoblin, huugeurl.com |
| 13:39 | necrodearia | s/uu/u/ |
| 13:40 | UukGoblin | lol ;-] |
| 13:40 | nanotube | UukGoblin: er... no it isn't. |
| 13:41 | nanotube | UukGoblin: you linked page3 of the thread, i linked page 8 |
| 13:41 | UukGoblin | oic |
| 13:42 | idev | thank nanotube, do i just place the whole bitcoin dir in my apps folder ? |
| 13:42 | UukGoblin | yeah I missed a 1 or something |
| 13:43 | nanotube | idev: see what gavinandresen said a few lines above. you should get the zip specifically for the mac, and extract stuff from the zip. |
| 13:43 | nanotube | idev: i know little about how present-day macs deal with their apps... so beyond that, you're on your own :) |
| 13:47 | idev | Hmm, i moved bitcoin.aap to my appliaction folder but my mac is saying " you cannot open the application "Bitcoin" it is not supported on this architecture" ? |
| 13:47 | idev | does this mean i can not run btc on my mac? |
| 13:50 | UukGoblin | idev, you can surely run bitcoin on your mac |
| 13:50 | UukGoblin | not sure what the problem is, but I'm guessing if you compiled it from source it might work |
| 13:50 | gavinandresen | Are you running on an older mac? (non-intel)? |
| 13:51 | idev | no its not |
| 13:51 | idev | yea non intel |
| 13:51 | gavinandresen | PowerPC macs aren't supported... sorry! Compling from source won't work on them, either. |
| 13:52 | idev | ok then, please can you tell me how i can install on my webserver please? |
| 13:53 | gavinandresen | Can you ssh into your web server and get a command prompt? |
| 13:53 | idev | i don't really know about ssh commands so please go easy |
| 13:53 | idev | yes |
| 13:54 | gavinandresen | Right, I'd probably download the linux .tar.gz file on my mac, and then copy just the bitcoin executable up to the server (using scp ) |
| 13:55 | idev | where do i have to place bitcoin on the server? |
| 13:56 | gavinandresen | it can live anywhere-- your home directory would be fine. If you have root access, /usr/local/bin/ would be a better place. |
| 13:56 | gavinandresen | And I'd suggest copying up bitcoind -- with a "d" on the end. It is the no-graphics bitcoin. |
| 13:56 | gavinandresen | (unless you're running a X-windows server on your mac) |
| 13:57 | idev | can i use use the gui version on the webserver? |
| 13:58 | gavinandresen | Once you've copied bitcoind up to the server, ssh there and run these commands: |
| 13:58 | gavinandresen | mkdir .bitcoin |
| 13:58 | gavinandresen | echo "rpcpassword=foo" > .bitcoin/bitcoin.conf |
| 13:58 | gavinandresen | ./bitcoind |
| 13:59 | idev | thank you very much Gavin, gonna have a try now |
| 13:59 | gavinandresen | Then wait a little while for bitcoind to start up; I think it puts itself in the background on linux. |
| 13:59 | idev | ok |
| 13:59 | gavinandresen | You can see it's progress by: tail -f .bitcoin/debug.log |
| 13:59 | gavinandresen | ... and you can send it commands by running ./bitcoind help |
| 14:00 | idev | ok thank you Gavin |
| 14:00 | gavinandresen | good luck |
| 14:01 | idev | Thanks im gonna need it lol |
| 14:01 | gavinandresen | idev: re: can you run the GUI version on the webserver: sure, bitcoin on linux/unix is an X11 application, it'll display to any X-capable device. |
| 14:02 | nanotube | gavinandresen: would you have any thoughts on this: http://www.bitcoin.org/smf/index.php?topic=1306.0 |
| 14:02 | bitbot | I broke my wallet, sends never confirm now. |
| 14:03 | gavinandresen | nanotube: my first thought is "if you play with fire, don't get upset if you get burned..." (a little unfair, since kermit isn't actually very upset about this) |
| 14:04 | nanotube | gavinandresen: well... but i am - he sent me those transactions, and now they're in my wallet. |
| 14:04 | gavinandresen | nanotube: very good point |
| 14:04 | nanotube | gavinandresen: and i wonder if the client prioritizes sending the most-confirmed coins first, or not? because if not, it's possible that my next outgoing transaction will include them, and will never be confirmed. |
| 14:05 | nanotube | gavinandresen: and if that's the case, that means /someone/ can screw over the network by sending no-fee 0.0001 to all the addresses he finds on the net. |
| 14:05 | nanotube | so a bunch of wallets get 'contaminated' with these never-to-be-confirmed transactions, which will propagate if client doesn't prioritize by confirmations. |
| 14:06 | gavinandresen | nanotube: the client trys to do a "best fit" when selecting coins; I don't think it cares about number of confirmations, so, yeah, that's a very valid worry. I'll ping Satoshi about it. |
| 14:07 | gavinandresen | Easy fix would be to have the client NOT select 0-confirmation coins unless it absolutely has to. And maybe have 0-confirmation coins expire after a reasonable amount of time. |
| 14:08 | kermit | gavinandresen: i'd think sending 0 conf coins at all is dangerous |
| 14:09 | kermit | at least not without a user who needs really fast turn around selecting some option, maybe |
| 14:12 | nanotube | gavinandresen: thanks - please keep me posted. guess i should avoid sending from my wallet until the next version of bitcoin is released which avoids sending unconfirmed bitcoins unless absolutely necessary. |
| 14:12 | nanotube | ? |
| 14:12 | kermit | well, i think i sent some of these to bitcoinmarket |
| 14:13 | kermit | so if this is contageous, im not sure how much damage your wallet will do |
| 14:13 | theymos | Can't Bitcoin just ask peers for the transaction to see if they have it before sending it? |
| 14:15 | MacRohard | it already knows there are no confirmations |
| 14:17 | UukGoblin | huh, betco.in just didn't register my flush |
| 14:17 | theymos | MacRohard: That just means it hasn't appeared in a block. Peers can still have it in their memory pools. |
| 14:17 | UukGoblin | I had a bloody flush! |
| 14:17 | UukGoblin | and my opponent won with 2 pair |
| 14:18 | gavinandresen | nanotube: unless you send ALL the coins in your wallet, the micro-coins will most likely stay in your wallet. (I'm staring at the SelectCoins code in another window, and it trys pretty hard to find the smallest set (number) of coins that satisfy the payment) |
| 14:19 | nanotube | well, the client also doesn't show the sigdigits of the microtransactions, they all look like 0.00 |
| 14:20 | nanotube | but i guess i should be able to calculate and see how much of by balance is due to confirmed transactions and how much is from micros |
| 14:20 | nanotube | (though i have some confirmed micros as well...) |
| 14:21 | kermit | gavinandresen: it tries to find the smallest set? but isnt there something about trying to consolidate as much as possibel to? |
| 14:22 | kermit | or, if you have 6,1,1,1, and send 3, does it brake the 6 or take the 3? |
| 14:22 | gavinandresen | It'll take the 1,1,1 |
| 14:23 | theymos | It always chooses the smallest coins, right? |
| 14:24 | gavinandresen | No, it doesn't always choose the smallest. |
| 14:25 | theymos | How does it choose? |
| 14:26 | gavinandresen | It: shuffles all your coins. Then adds up the first ones until they add up to the payment or greater. |
| 14:26 | gavinandresen | ...wait, hang on, that's not quite right... |
| 14:28 | gavinandresen | Shuffles coins.... looks for the smallest coin that is bigger than the payment amount.... OR for a coin that is equal to the payment amount... |
| 14:31 | gavinandresen | Ok, if I'm reading the code correctly (I'd say there's a 25% chance I am not): if there is a coin in your wallet that matches the payment amount, it is used. |
| 14:32 | gavinandresen | If there is a set of small coins in your wallet that add up to more than the payment amount, then the "best" subset of them is chosen. |
| 14:33 | gavinandresen | Otherwise, all of the small coins in your wallet PLUS the smallest-coin-that-is-less-than-the-payment are chosen. |
| 14:34 | idev | Hello gavin |
| 14:34 | idev | im seem to be a but stuck |
| 14:34 | gavinandresen | Howdy idev, what's up? |
| 14:34 | theymos | Thanks. It's a very confusing section of code; I can't make heads or tails of it. |
| 14:35 | idev | i have uploaded bitcoin to my server and have run the cmds, mkdir .bitcoin and echo "rpcpassword=foo" > .bitcoin/bitcoin.conf |
| 14:35 | idev | but when i try to run ./bitcoind it says file or dir is unknown |
| 14:36 | idev | wonder where im going wrong |
| 14:36 | gavinandresen | idev: if you "ls -l" do you see bitcoind ? |
| 14:37 | idev | ah my bad i forgot to untar the file |
| 14:37 | idev | what is the cmd to untar please? |
| 14:37 | gavinandresen | tar -xzvf *.tar.gz aught to work |
| 14:38 | gavinandresen | I don't remember if it untars into a subdirectory |
| 14:39 | idev | although i have not untared the file yet i have another dir called .bitcoin with bitcoind init? |
| 14:41 | gavinandresen | idev: yep. |
| 14:41 | gavinandresen | idev: wait, hang on, you already have a ./bitcoin/bitcoind ? |
| 14:41 | gavinandresen | idev: errr... .bitcoin/bitcoind ? |
| 14:42 | idev | it has bitcoin.conf |
| 14:42 | idev | in it |
| 14:42 | gavinandresen | ls -l .bitcoin should have the bitcoin.conf file in it with the rpcpassword set. |
| 14:42 | gavinandresen | That'll let you control the running bitcoind from the command-line after you get it running. |
| 14:43 | gavinandresen | (oh, and if you share your webserver machine, you should set the permissions on the .bitcoin folder so other users can't steal your wallet: chmod go-rwx .bitcoin ) |
| 14:44 | idev | ok, im goona untar now and see how it goes |
| 14:44 | idev | thansk gavin |
| 14:44 | idev | thanks* |
| 14:45 | kermit | who wants a free .05btc that will never confirm? |
| 14:46 | edcba | what satoshi wanted to 'solve' with coin selection ??? |
| 14:48 | gavinandresen | edcba: hmm? the second part of the coin selection code is a stochastic approximation to solve the 'knapsack problem'.... |
| 14:49 | edcba | why use that ? |
| 14:49 | gavinandresen | .. so if you have coins of value 1,2,3,4,9 and you want to make a 10 bitcoin payment, it'll pick the set [1,2,3,4] or [1,9] instead of [9,4] with change left over |
| 14:52 | edcba | isn't it less anonymous ? |
| 14:53 | gavinandresen | edcba: less anonymous than what? Picking a random set of coins that adds up to more than the payment amount? |
| 14:53 | edcba | yes |
| 14:54 | gavinandresen | edcba: I dunno, you'd have to ask a cryptographer who studies that sort of thing. Personally, I think if you're worried about getting tracked via the coins flowing through your wallet you're probably NOT worrying about some much bigger threat to your anonymity. |
| 14:55 | theymos | I don't see any point in reducing change. It should reduce number of inputs so that you have less fees. |
| 14:55 | edcba | yes i still don't see what satoshi aims |
| 14:56 | necrodearia | theymos, Hiya. Can you verify/confirm http://www.bitcoin.org/smf/index.php?topic=1303.msg14566#msg14566 ? |
| 14:56 | bitbot | Selling 50,000+ BTC at $0.04/BTC : bitcoin2cash: If that's the case then you should already be able to see the number of bitcoins sent to my address which is 1CRZpkKKAt7G5uiK4JPBjBJGnozgiatFAs. |
| 14:57 | gavinandresen | Well, my 'refundtransaction' git branch refactored that code a little bit which would make it easier to experiment with custom clients that have alternative coin-selection policies. |
| 14:57 | gavinandresen | (refundtransaction trys to refund the coins it got from transaction being refunded....) |
| 15:08 | kermit | bitcoinmarket doesnt seem to credit me until a transaction is confirmed. do they have special code or is there some way to do that with bitcoind ? |
| 15:08 | theymos | necrodearia: The address has at least 25,000 (I'm using old data; he could have more), though there's no proof that he owns that address. He should make a new address and send all of the coins to that one, and publish the block number when he does it. |
| 15:08 | echelon | they just use the rpc to check the confirmation |
| 15:09 | echelon | kermit, i don't think anyone sane would process transactions until they reach a confirmation threshold :/ |
| 15:09 | necrodearia | theymos, That is true, however, a google search does indicate that it is only publicized by them. |
| 15:10 | kermit | echelon: how do i 'use the rpc' ? |
| 15:10 | kermit | echelon: oh i fonud it |
| 15:10 | echelon | kermit, have to pass -server as an argument to bitcoin |
| 15:10 | echelon | or run bitcoind |
| 15:10 | theymos | necrodearia: He could have easily parsed the block chain himself and found an address that has a suitable balance. |
| 15:10 | necrodearia | Additionally |
| 15:10 | necrodearia | One of the sites is in russian |
| 15:10 | necrodearia | So it could be yet another Russian scam ^_^ |
| 15:10 | kermit | echelon: getreceivedby.. |
| 15:10 | necrodearia | That is true also |
| 15:11 | echelon | kermit, http://www.bitcoin.org/wiki/doku.php?id=api |
| 15:11 | echelon | the json-rpc runs on port 8332, once you've added the login/pass to bitcoin.conf |
| 15:11 | grondilu | THE MORE I THINK ABOUT THIS THE MORE I GET CONVINCED THAT BITCOIN ARE ABOUT TO CHANGE THE WORLD !!!!! |
| 15:12 | echelon | :) |
| 15:12 | echelon | the more it changes the world, the more it will come under attack by feds unfortunately -__- |
| 15:13 | idev | Sorry Gavin to keep troubling you, but i can't seem to get BTC going, ive uploaded the .gz, ran the cmds mkdir .bitcoin echo "rpcpassword=foo" > .bitcoin/bitcoin.conf, but when i run ./bitcoin it says it file or dir unknow |
| 15:13 | grondilu | they can very few. THey'll do what they did with gold : they'll try to corner it. But this will only increase its value. |
| 15:14 | echelon | perhaps |
| 15:15 | kermit | idev: ldd bitcoin |
| 15:15 | kermit | grondilu: i agree with what yuo said in CAPS |
| 15:16 | grondilu | And with gold, they can steal it to honnest citizens, as they did in USA during the 30s. With bitcoins, unless they start torturing people to obtain their passphrases, they will not be able to steal. |
| 15:16 | idev | @ Kermit sorry i dont understand? |
| 15:16 | kermit | echelon: thast why i'd like to see it be 100% distrubuted, not 99% .. it needs an easy way to add IP addresses on start in case the irc server isnt avalailble |
| 15:17 | kermit | idev: type: ldd bitcoin |
| 15:17 | echelon | kermit, what it needs is dht -_- |
| 15:17 | echelon | not hard-coded nodes |
| 15:17 | theymos | kermit: You can use -addnode, and there are built-in seednodes used as a backup bootstrap source. |
| 15:17 | idev | @ Kermin ./bitcoin: No such file or directory |
| 15:18 | idev | kermit* |
| 15:18 | grondilu | kermit: getting new connection is not that difficult. Worst case scenario, some websites would act like trackers. |
| 15:18 | echelon | idev, uhm.. do you know where bitcoin is? |
| 15:19 | idev | 1 sec, @ echelon |
| 15:19 | echelon | enter this.. find . -name bitcoin |
| 15:19 | kermit | theymos: i was told there are built in seednodes, but it didnt seem to work without access to the irc server |
| 15:19 | theymos | kermit: It waits a long time before it contacts them. It's also possible they're all down; they're not very reliable. |
| 15:20 | idev | its loacted @ /googserv.co.cc/bitcoin-0.3.12/bin |
| 15:20 | idev | but theres a 32 and 64 dir |
| 15:20 | echelon | ok so, run.. |
| 15:20 | kermit | a few dynamicly updated hostnames in various TLDs would be really nice :) |
| 15:20 | echelon | are you on a 32bit or 64bit cpu? |
| 15:21 | idev | im not sure, but more than likly its 32 |
| 15:21 | idev | how do i run it please? |
| 15:21 | idev | what do i nned to type |
| 15:21 | echelon | ok so, run.. /googserv.co.cc/bitcoin-0.3.12/bin/32/bitcoin |
| 15:22 | echelon | that ^ |
| 15:22 | theymos | kermit: There's a list of always-up peers: http://www.bitcoin.org/smf/index.php?topic=59.msg that you can use. |
| 15:22 | bitbot | Post your static IP |
| 15:22 | echelon | with the paths |
| 15:23 | idev | Ok now its prompting me to download bitcoin from that path |
| 15:23 | echelon | theymos, why did you add a dns in that thread? |
| 15:23 | echelon | idev, what exactly does it say? |
| 15:23 | kermit | is anyone using CUDA in linux for bitcoin? |
| 15:23 | echelon | i wish :/ |
| 15:24 | echelon | that'd be cool |
| 15:24 | idev | you have chossen to open bit coin with ..... |
| 15:24 | necrodearia | Isn't CUDA proprietary? |
| 15:24 | theymos | echelon: It's a DynDNS hostname. I have a dynamic IP (though my IP rarely actually changes). |
| 15:24 | echelon | theymos, bitcoin only handles static ip's unfortunately :/ |
| 15:25 | echelon | wait |
| 15:25 | echelon | is it the same case if you manually add them? |
| 15:25 | idev | @ echelon, its says you have chossen to open bit coin with ..... from googserv.co.cc |
| 15:25 | necrodearia | http://is.gd/fAtaT |
| 15:26 | echelon | i don't know what that means |
| 15:32 | theymos | echelon: You can resolve my hostname and then use the IP. |
| 15:32 | echelon | oh ok |
| 15:34 | echelon | if bitcoin only uses socks4, will adding a tor hidden service address work? |
| 15:35 | theymos | echelon: No. |
| 15:35 | echelon | so why did people add them to the thread? -_- |
| 15:35 | theymos | echelon: You might be able to use Tor's MapAddress option to make it work, though. |
| 15:36 | echelon | hmm |
| 15:47 | necrodearia | hmm, when I `svn co https://bitcoin.svn.sourceforge.net/svnroot/bitcoin bitcoin` I see "Error validating server certificate for 'https://bitcoin.svn.sourceforge.net:443':" |
| 15:48 | necrodearia | http://pastebin.com/hfu8D8R6 |
| 15:48 | necrodearia | I haven't noticed this previously. |
| 15:49 | theymos | Equifax is a pretty common CA. Do you have your CAs set up correctly? |
| 15:49 | necrodearia | I imagine not. |
| 16:06 | idev | when i run i get ./bitcoind: Permission denied, and way to fix this and make it work |
| 16:06 | kermit | idev: chmod +x bitcoind |
| 16:07 | kermit | though it comes +x, where'd the +x do? |
| 16:08 | jgarzik | kermit: +x: "+" == add permission of type <blah>, "x" == the execute permission. "+x" == mark bitcoind executable. |
| 16:08 | jgarzik | kermit: man chmod :) |
| 16:08 | idev | ok now i get ./bitcoind: error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file: No such file or directory |
| 16:08 | kermit | jgarzik: you mean idev: |
| 16:09 | jgarzik | kermit: "where'd the +x do?" was strange English, interpreted as asking what "+x" does |
| 16:09 | jgarzik | kermit: so it was directed at you :) |
| 16:09 | kermit | oh, typo, i meant go not do |
| 16:10 | kermit | idev: what system is this? |
| 16:11 | idev | Debian Linux |
| 16:12 | kermit | idev: apt-get install libgthread or gthread |
| 16:12 | idev | whats the cmd for that please Kermit? |
| 16:13 | jgarzik | gthread is inside glib 2.0 |
| 16:14 | jgarzik | surely debian doesn't split out gthread into a separate deb? |
| 16:14 | idev | i don't have a clue about most of this tech stuff to be honest |
| 16:23 | kermit | so bitcoinmarket doestn credit you for btc until its confirmed, but how do they send out btc without using the unconfirmed btc? |
| 16:23 | kermit | i dont see any way in the bitcoind i have that gives you the option to specify |
| 16:23 | jgarzik | kermit: which confirmations do you speak of -- bitcoin network confirmations, or bitcoinmarket trade confirmations? |
| 16:24 | kermit | jgarzik: bitcoin network |
| 16:24 | jgarzik | kermit: BCM appears to wait for a confirmation or two, on incoming bitcoin transactions. Therefore, any bitcoins you withdraw (outgoing bitcoin transactions, from BCM's perspective) are highly likely to be network-confirmed and safe. |
| 16:25 | kermit | is it using a seperate wallet for everyone? |
| 16:25 | jgarzik | kermit: unlikely, but I cannot say for sure. |
| 16:26 | kermit | jgarzik: so how are the unconfirmed lots not being sent out with the confirmed ones? |
| 16:28 | jgarzik | kermit: it pretty much follows the standard bitcoin algorithm for coin selection |
| 16:29 | jgarzik | kermit: main.cpp, SelectCoins |
| 16:30 | kermit | jgarzik: right.. are you suggesting that has a preference for confirmed coins? |
| 16:31 | jgarzik | kermit: it's quite complicated, a random shuffle among other things (see gavin's explaination above). no suggestion or implication. it appears that SelectCoins() does not check confirmations, but I could be missing something. |
| 16:32 | kermit | then what do you base this claim on "n incoming bitcoin transactions. Therefore, any bitcoins you withdraw (outgoing bitcoin transactions, from BCM's perspective) are highly likely to be network-confirmed and safe." |
| 16:33 | kermit | just odds? |
| 16:34 | jgarzik | kermit: it doesn't make bitcoins available to any user, on the website, until incoming confirmations have been received. considering that a large number of bitcoins are sitting at BCM at any given time, there is a high likelihood you will get confirmed coins on outgoing tx's. it's only a tiny percentage of BCM's total coins that are unconfirmed, at any given moment. |
| 16:35 | jgarzik | kermit: to get unconfirmed coins, it takes an unlikely scenario such as: a large bitcoin deposit, swamping the entire market, occuring at the same time as a large number (size-wise) of withdrawals |
| 16:36 | bonsaikitten | an intriguing challenge |
| 16:41 | echelon | is there a way to add nodes in bitcoin.conf? |
| 16:41 | theymos | echelon: You can use addnode=x. All of the command-line options work in bitcoin.conf |
| 16:42 | echelon | oh cool, thanks :) |
| 16:42 | echelon | so if i want to run the server, i just add a line with "server"? |
| 16:43 | theymos | I don't know. Maybe server=1. |
| 16:43 | echelon | and addnode values aren't delimited by commas? |
| 16:43 | theymos | echelon: do multiple addnodes. |
| 16:43 | echelon | ok |
| 17:07 | echelon | so.. all dns need to be resolved to an ip before adding them with addnode? |
| 17:27 | echelon | cool.. lfnet allows tor |
| 17:29 | xelister | Im convincing author of freenet ( #freenet ) to accept donations in BTCs |
| 17:29 | xelister | anyone wanna help to explain how this works on #freenet ? ;) |
| 17:30 | echelon | heh |
| 17:30 | nanotube | xelister: well... the freenet guys should be quite educated on the various ideas of cryptography. maybe you should just send them to read the bitcoin pdf whitepaper (and also the site and wiki) |
| 17:30 | echelon | you can say that he doesn't have to replace the existing payment system |
| 17:31 | echelon | just add the option |
| 17:31 | echelon | maybe don't think as many people would be willing to donate |
| 17:31 | echelon | *maybe they don't |
| 17:31 | nanotube | true, the "just an option" bit is a pretty good thing to point out. |
| 17:32 | xelister | nanotube: the developer have now milion things to do so not very much time for BTC... but it would be cool if they accepeted it |
| 17:32 | nanotube | as in, they'd not be losing any other donations, but only gaining btc donations. |
| 17:32 | xelister | time, effort |
| 17:33 | nanotube | mmm |
| 17:37 | xelister | "xelister: given that our experience of alternative currencies is that nobody ever uses anything except paypal, it might happen if you were to promise some actual money" |
| 17:38 | xelister | huhm.. we indeed need to promote BTC :) |
| 17:38 | xelister | we may start by typing /j #freenet perhaps |
| 17:38 | kermit | i think bitcoin is good enough that it doesnt need promotion |
| 17:38 | kermit | well, still tell your friends of course |
| 17:40 | nanotube | xelister: you can point out that btc can be exchanged for usd |
| 17:40 | xelister | yeah I did, but the question is, what is the effort |
| 17:43 | nanotube | xelister: well... tbh... unless you can convince him that there /will be a lot of people donating btc/, it is indeed not worth the effort. |
| 17:45 | echelon | ok, if i'm using the socks proxy setting with bitcoin.. shouldn't the `netstat -natp | grep bitcoin` show only connections to the socks proxy? |
| 17:45 | echelon | does the socks proxy setting even work? |
| 17:52 | echelon | the only way to force it is to torify it |
| 17:54 | kermit | bitcoin should use UDP packets with made up source addresses to send payments |
| 17:54 | kermit | most ISPs dont filter that |
| 17:55 | kermit | ..maybe one day it will |
| 17:56 | echelon | oh weird.. it was off for some reason |
| 17:59 | xelister | it seems 20-30% are lost when using bitcoins in eur -> btc -> eur ? |
| 17:59 | xelister | are there markets with better preserving? |
| 18:00 | grondilu | just do : eur -> btc ------very long time------> eur :-) |
| 18:01 | nanotube | well, the markets are pretty thin at the moment, so the bid-ask spreads are fairly large. but the mkt in usd seems to be more active and with smaller spreads |
| 18:01 | xelister | ; markets |
| 18:08 | nanotube | hey, trying to compile bitcoind... at the last step i'm getting "/usr/bin/ld: cannot find -lgthread-2.0" ... anyone know what library that lives in? |
| 18:08 | kermit | intstall liblogthread-dev ? |
| 18:09 | kermit | er n/m no |
| 18:09 | nanotube | heh yea that came up in apt-cache search for me too, but doesn't look like a relevant lib. |
| 18:10 | soultcer | Install glib |
| 18:10 | soultcer | (libglib2.0-dev) |
| 18:11 | nanotube | soultcer: heh yea thanks - just found some refs to that on the web, trying now. :) |
| 18:11 | nanotube | soultcer: yay, worked! thanks :) |
| 18:12 | xelister | <toad_> xelister: i don't get it, if every node has to have a full history how can that scale? |
| 18:12 | xelister | how? |
| 18:13 | nanotube | xelister: i've heard something about in the future storing abbreviated/condensed histories... |
| 18:13 | nanotube | but no idea of the details. |
| 18:14 | echelon | does mybitcoin.com have a clearnet address? |
| 18:20 | warner | xelister: my thought is that the nodes that store a full history could offer verification services to those who don't |
| 18:21 | xelister | thanks |
| 18:21 | xelister | bbl |
| 18:22 | warner | as a client of such a service, you'd want to subscribe to several different (hopefully independent) providers, so that any single one couldn't trick you by themselves |
| 18:23 | toad_ | fyi i have no issue with archiving my comments, we used to do the same thing on #freenet |
| 18:24 | glavkos | no problem with the creation of an archive |
| 18:26 | toad_ | is there a technical faq? i have some technical questions ... 1) do all bitcoin peers have to receive all transactions, or at least a fixed proportion of all transactions? 2) how good is privacy - i haven't read the full paper, it suggests there may be some linkability? 3) will bitcoin drive ever increasing CPU energy usage? :) |
| 18:26 | warner | toad_: I can try to answer some of them from what I've gleaned from the code |
| 18:26 | toad_ | 1 equates to "how do bandwidth requirements for a peer scale with the total number of transactions going on globally" |
| 18:27 | warner | 1) to verify that any given transaction hasn't been double-spent, you need to have received all transactions. You might be able to delegate that job to somebody else. |
| 18:27 | warner | you don't have to store all transactions, but you do have to receive them. (you only store a list of the unspent ones) |
| 18:27 | toad_ | as i see it, bitcoin basically replicates the spend-tracker across all nodes, and then eliminates the need for a trusted mint as well by creating time/cpu-based scarcity |
| 18:27 | warner | yeah, that's a good summary |
| 18:28 | toad_ | okay, so if it was ever to get big, the nodes would all have to have huge bandwidth? |
| 18:28 | toad_ | on the other hand, if you disconnect and reconnect you don't need the full history, you can get away with a short hash chain |
| 18:28 | warner | the hashcash aspect serves two purposes: a nominally-fair way to distribute the initial currency, and a way to ensure the immutability of the spend record |
| 18:28 | kermit | hrm i just got a shell on a 16 core 3GHz xeon system, but bitcoin didnt run: ./bitcoin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./bitcoin) |
| 18:28 | smop | i've always wondered what the hashes are gowing towards |
| 18:29 | toad_ | so it has no real issues with unreliable peer to peer as long as bandwidth isn't a big deal |
| 18:29 | warner | toad_: yeah |
| 18:29 | kermit | toad_: there's a pdf that is very technical |
| 18:29 | warner | it's currently flooding the unbound transactions and completed blocks to everyone |
| 18:29 | toad_ | yeah, i haven't read the whole thing yet |
| 18:29 | toad_ | any ideas on questions #2 and #3? |
| 18:29 | warner | but nodes only ask for the blocks/txns that they want |
| 18:30 | warner | 2) privacy is meh |
| 18:30 | warner | from what I can tell, it's not a primary design goal |
| 18:30 | warner | the transaction record means that each txn is easily linked to its predecessors |
| 18:30 | toad_ | well, the first level is keeping public keys anonymous; this is pointless |
| 18:30 | toad_ | in that you can link stuff easily once you id the key, you can likely id the key from the linkages |
| 18:31 | warner | each "coin" (i.e. an unspent output of a transaction [which can have multiple inputs and multiple outputs]) can have a distinct single-use pubkey |
| 18:31 | toad_ | it also says "a new key pair should be used for each transaction ... some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner" ... |
| 18:31 | warner | but the (current) most common use case is the donation button, which has a publically-known pubkey |
| 18:31 | toad_ | okay ... |
| 18:32 | warner | so you can grep the transaction log for all txns that have that pubkey in the output, and see how much $ they've been given and which keys it came from |
| 18:32 | toad_ | but if you wanted it to be private, you could effectively maintain thousands of separate accounts, and then send a bunch of them to the person who wants to send you the money? |
| 18:33 | warner | toad_: each transaction can transfer BTC to a new pubkey, and yeah, you can make those very cheaply (they're just ECDSA keypairs) |
| 18:33 | toad_ | so then the obvious way to link the transactions is by time ... |
| 18:34 | warner | you just need to give someone the pubkeys in secret, so an observer can't link them |
| 18:34 | warner | and obviously you have to publish the resulting transactions to the world in such a way that an observer can't link them to e.g. your IP address |
| 18:34 | toad_ | the paper says "some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner" ... I guess that's a reference to a timing attack |
| 18:35 | echelon | so you're supposed to send cash in the mail to bitcoin2cash.com? |
| 18:35 | necrodearia | Yay, update from Michael Chisari of The Appleseed Project |
| 18:35 | warner | to get serious unlinkability, I suspect that you'd need to have some sort of remixer-like service, in which you pay them BTC at some fixed rate, and they pay it back to you later (to new keys) in some unrelatedly-looking rate |
| 18:35 | echelon | folded inside paper i'm guessing? |
| 18:35 | necrodearia | Tis kind of sad that still Appleseed community is tiny at 6 users |
| 18:35 | echelon | so that it can't be seen from the outside? |
| 18:35 | warner | toad_: no, I don't think the paper considers timing attacks |
| 18:35 | necrodearia | and a day prior to diaspora launch, diaspora chan had about 10 users. |
| 18:35 | toad_ | warner: then how are transactions linkable? |
| 18:36 | warner | toad_: each "transaction" contains some number of inputs and some number of outputs |
| 18:36 | necrodearia | Now 90-100 users. |
| 18:36 | warner | toad_: each output is a single-use amount of BTC |
| 18:36 | necrodearia | The media attention seems to be what attracts community rather than the better or first implemented project/community |
| 18:36 | toad_ | warner: well to keep them separate you'd need to do a separate transaction, from the network's point of view, for each private account |
| 18:36 | necrodearia | This applies to Bitcoin also |
| 18:36 | warner | more specifically, each output is a ($BTC, pubkey) pair |
| 18:36 | warner | toad_: the input is a reference to some earlier output |
| 18:37 | toad_ | okay ... |
| 18:37 | necrodearia | e.g. Bitcoin may be best implementation of its kind, however, another implementation that has better media support will definitely garnish more attention |
| 18:37 | warner | and the whole transaction is signed by all the keys from all of the linked earlier outputs |
| 18:37 | necrodearia | It will be rather saddening when such an event related to Bitcoin does occur =\n4770 |
| 18:38 | necrodearia | However |
| 18:38 | warner | toad_: so the "linkability" concern mentioned in the paper is that, if you see a txn that says "inputs A, B, and C shall be consumed and their value granted to keys D and E", then you can safely assume that A,B, and C are all controlled by the same entity |
| 18:38 | necrodearia | Bitcoin community is definitely a much larger community than The Appleseed Project has established |
| 18:38 | toad_ | warner: okay |
| 18:39 | toad_ | warner: so you can avoid that simply by using separate network-level transactions for a single high-level transaction (e.g. purchase) |
| 18:39 | toad_ | but then you get into timing attacks |
| 18:39 | necrodearia | My apologies toad_, echelon and warner if my topic is seemingly interruptive of your conversation |
| 18:39 | toad_ | plus, it uses more bandwidth |
| 18:39 | toad_ | necrodearia: not a problem for me |
| 18:40 | warner | toad_: the bitcoin client maintains a "wallet", with a list of (output_reference, value, privkey), which I think of as "coins". When you spend e.g. 50BTC to Bob's pubkey D, the client will find enough "coins" to total to >=50, create a new keypair, then publish a txn that has all those coins as inputs, and has two outputs: one to D for 50BTC, and one to the new keypair with the leftover change |
| 18:40 | echelon | hey, how'd you get toad_ in here? :D |
| 18:40 | warner | toad_: so the observer gets to see that the change is associated with those keys too |
| 18:40 | warner | necrodearia: no worries :) |
| 18:41 | warner | toad_: yeah, you'd want to send each "coin" in a separate transaction, and spread them out over time |
| 18:41 | necrodearia | 5btc to third person to provide a response to the topic I mentioned just a couple minutes ago. ^_^ |
| 18:41 | warner | which makes commerce more challenging too, when you don't get atomic payments |
| 18:41 | toad_ | echelon: xelister |
| 18:41 | echelon | :) |
| 18:42 | toad_ | echelon: suggesting that FPI take donations in bitcoin form, /me is skeptical for several reasons but when he told me about the architecture i thought it was fascinating... |
| 18:42 | necrodearia | echelon, That response doesn't cunt ^_^ |
| 18:42 | necrodearia | count* |
| 18:42 | warner | toad_: it doesn't get invoked much now, but the client has rules to discourage lots of tiny transactions (in the form of fees that must be paid when the txn value is too small) |
| 18:43 | warner | toad_: me too, I've spent the last few weeks being captivated by this system. it appears to be very carefully thought out. |
| 18:43 | toad_ | warner: so generally there is no privacy at the moment; very good privacy is possible but would likely be very expensive and require many trusted-but-verifiable mixer intermediaries |
| 18:43 | warner | (I keep thinking of ways to tie it into Tahoe, of course, but haven't gotten there yet) |
| 18:43 | toad_ | given intermediaries, it could in fact be reasonably cheap |
| 18:43 | warner | yeah, that sounds about right |
| 18:44 | warner | it's not completely impossible, as some schemes would make it |
| 18:44 | toad_ | but it will always cost noticeably more than no-privacy operation |
| 18:44 | toad_ | okay |
| 18:44 | warner | but it's not specifically designed for privacy (unlike a lot of digital cash schemes) |
| 18:44 | warner | it's much more focussed on decentralization and predictable economic behavior |
| 18:45 | toad_ | and the answer to question 1 was that bandwidth is indeed proportional to the number of transactions going on, so if it was ever to become widely used, we would need really big nodes or several separate maybe interacting networks |
| 18:45 | warner | my big privacy concern would be retroactive linkability |
| 18:45 | warner | yeah |
| 18:45 | toad_ | is several separate interacting networks feasible? |
| 18:45 | warner | not really |
| 18:45 | warner | there exists a single global append-only (-ish) transaction record |
| 18:46 | warner | not everybody needs to follow it, but at least somebody does |
| 18:46 | warner | and if you don't follow it yourself, then your double-spend protection is dependent upon whoever does |
| 18:46 | toad_ | so long term we will need nodes with truckloads of bandwidth? |
| 18:47 | warner | but there's room there for some specialization and delegation |
| 18:47 | toad_ | well yeah |
| 18:47 | warner | some, yeah |
| 18:47 | toad_ | and even given that it will be a far more decentralised and transparent system than the standard banking model |
| 18:47 | warner | yup |
| 18:47 | warner | I especially like the predictable rate of inflation |
| 18:48 | toad_ | there is built-in inflation, so it's a medium of exchange, not of accumulation ... |
| 18:48 | toad_ | you buy an investment, or you even put money into a "bank account" ... later on you get more out |
| 18:48 | toad_ | okay |
| 18:48 | toad_ | what about question 3? |
| 18:48 | warner | the number of BTC in existence is predictable far in advance |
| 18:48 | warner | until the end of time, really |
| 18:49 | warner | yeah, so yes, the popularity of the system tends to increase the demand for CPU time, but I think it's limited |
| 18:49 | toad_ | that is, will BTC cause competition between money printers to use more and more CPU time? |
| 18:49 | toad_ | what is it limited by? |
| 18:49 | edcba | electricity price |
| 18:49 | warner | people who run "mining"/generation nodes burn CPU time to increase the fraction of the fixed BTC/hour that they capture |
| 18:49 | xelister | "<warner> you just need to give someone the pubkeys in secret, so an observer can't link them" |
| 18:49 | xelister | ^--- like, over Freenet, woo o/ |
| 18:50 | echelon | toad_, i've heard people are already sending their wallets over freenet |
| 18:50 | echelon | bitcoin wallets* |
| 18:50 | warner | but if the market value of BTC is less than the cost of the CPU you're burning, you lose the incentive to run the generating node |
| 18:50 | toad_ | well, people run generator nodes, can we be confident that the return from a generator node is always going to be low enough that it's not going to add up to a large fraction of total global electricity demand? |
| 18:50 | warner | so you stop |
| 18:50 | edcba | toad_: it should stabilise |
| 18:50 | warner | hm, I don't know |
| 18:51 | toad_ | you get to print money, but the rate at which you can do so is severely limited ... |
| 18:51 | warner | 50BTC every 10 minutes |
| 18:51 | xelister | echelon: are ther cli commands to expor X btc into other walletfile? and import? |
| 18:51 | edcba | if ppl stops, difficulty is lower, so it becomes affordable again... |
| 18:51 | echelon | i dunno, i haven't tried it myself |
| 18:51 | warner | the system overall adjusts the difficulty level to achieve one block every 10 minutes |
| 18:51 | toad_ | edcba: right, but do we have any reason to think that the total cost will remain below some reasonable level? |
| 18:52 | echelon | xelister, i don't think there is.. you would have to send X btc into another wallet |
| 18:52 | echelon | that's what was explained to me |
| 18:52 | warner | hm. I'm not even sure how to model it. |
| 18:52 | edcba | toad_: there will always be someone to generate bitcoins |
| 18:52 | edcba | even if he loses 'money' in the process |
| 18:52 | warner | each user is willing to spend A cycles just because it's cool, and then they'll spend B cycles because they think they can make money off of it |
| 18:53 | toad_ | hmmm |
| 18:53 | toad_ | this is something that needs a proper economist to model it |
| 18:53 | warner | and maybe C cycles because they feel they're contributing a public service (helping maintain the immutability/append-only-ability of the txn log) |
| 18:53 | xelister | and then, hopefully, spend C cycles to buy a domain, or donate to freenet ;) |
| 18:53 | warner | running a generator at all costs some amount, of hassle or setup time |
| 18:53 | edcba | toad_: if you want to spend your bitcoins you need to continue generating bloks ;) |
| 18:54 | toad_ | right, so you have the value of the generated blocks versus the cost of electricity to generate them |
| 18:54 | edcba | same for receiving them |
| 18:54 | xelister | you can limit the cpu usage however and then it will be nice in background |
| 18:54 | warner | and different participants have hardware that can generate at various hashes-per-second and dollar/watts-per-hash |
| 18:54 | toad_ | the cost of electricity determines the minimum price you can sell them for, and competition drives it down to roughly that level |
| 18:54 | warner | right |
| 18:54 | edcba | yes almost |
| 18:55 | xelister | or.. you can run bitcoin at full speed/cores, and 2 freenet nodes... and watch the PC burn its CPU and then HDDs :D |
| 18:55 | toad_ | however generators buying more hardware to get a larger slice of the output increases difficulty for other competitors |
| 18:55 | edcba | hmm yes *roughly* sorry |
| 18:55 | warner | so if everyone jumped in and ran generators just because they thought it was cool, the difficulty factor would rise very high, and the 6-blocks-per-hour would be spread very thin |
| 18:55 | toad_ | so you have the risk of an exponential arms race eventually becoming a top line item on global power/carbon budgets? |
| 18:55 | warner | so all of the rational participants, who could no longer justify the $ of running those CPUs, would drop out |
| 18:56 | edcba | toad_: also reward for block generation is divide by 2 each 2 years iirc |
| 18:56 | toad_ | well, the question is does rational participants buying new hardware drive up cpu prices? it would seem that it does ... |
| 18:56 | warner | if the total CPU of the irrational participants were great enough to keep the expected return lower than the cost of CPU, then the rational participants would never get back into the game |
| 18:57 | xelister | warner: by the game you mean being generators |
| 18:57 | warner | xelister: right |
| 18:57 | toad_ | warner: is there a bound on what the rational generators' are prepared to put in? |
| 18:57 | xelister | warner: they can easly just be regular users, running noed in background at low resources, and using real money to buy BTCs or sell real services for BTCs |
| 18:57 | edcba | toad_: also ppl may just generate bitcoins to have some cpu heaters ;) |
| 18:57 | toad_ | warner: as i see it, every time your competitor buys more hardware, that increases the bound, no? |
| 18:57 | xelister | and at that point BTC is becoming a real value |
| 18:57 | kermit | does anyone have a binary that works on RedHat???EL???5 ? |
| 18:58 | edcba | toad_: difficulty increase with total cpu power to match the 1 block every 10 minutes target |
| 18:58 | toad_ | exactly |
| 18:58 | warner | xelister: well, even running it in the background costs electricity, and a rational player would measure that. But yeah, the value of BTC is influenced both by the cost to generate it and the current market price. |
| 18:59 | toad_ | so if generator A buys more hardware, generator B's slower hardware becomes less valuable, and by buying more hardware generator B could increase his income |
| 18:59 | warner | true |
| 18:59 | warner | but eventually they'll bottom out |
| 18:59 | warner | er, the cost of that hardware will exceed the expected return |
| 18:59 | edcba | anyway what you forgot is BTC will be more easily acquired than generated at some point... |
| 19:00 | toad_ | well, there is an upper bound on the expected return |
| 19:00 | warner | as more people participate, (rather, as the $/BTC exchange rate goes down), the bound actually goes down |
| 19:00 | nanotube | warner: what's the cost of running [email protected] vs the benefit (to the individual). :) |
| 19:00 | xelister | warner: I think it cost really negligably amount of electricity, esp. if the CPU remains at low frequency (does not take niced proccessed in account for cpu freq governor) |
| 19:00 | toad_ | dependant on the size of the economy |
| 19:00 | toad_ | i.e. the $/BTC rate |
| 19:00 | toad_ | so there *is* an upper bound; whether it is acceptable is not clear |
| 19:00 | nanotube | warner: so... people who think the concept of bitcoin is valuable will continue to support the network with cpu cycles, even if it's not a profitable proposition in itself. |
| 19:00 | warner | nanotube: right, that's why I said *rational* participant :). I'm running a generator node just because it's cool, not because I expect to make money off of it |
| 19:01 | warner | I'm not rational :) |
| 19:01 | toad_ | i gotta go, thanks folks |
| 19:01 | toad_ | will lurk |
| 19:01 | nanotube | warner: well, there is rationality in supporting a system you want to succeed. |
| 19:01 | edcba | you may also want to keep it running for your bitcoins to earn value... |
| 19:01 | warner | toad_: yeah |
| 19:01 | warner | toad_: see you later |
| 19:02 | warner | nanotube: yeah, I meant the strict economic defintion of rational |
| 19:02 | warner | there's lots of indirect value to supporting a system that will benefit you in the future, but it's hard to capture in a model |
| 19:03 | edcba | it's just speculation :) |
| 19:16 | GuestofHonor | Although Bitcoin is not a game, perhaps it needs a kind of bribe to entice reviewers to review Bitcoin? http://games.slashdot.org/article.pl?sid=10/09/29/148242 |
| 19:17 | GuestofHonor | Additionally, perhaps the bribe will still allow the reviewer to review as they please and therefore not be a kind of typical bribe which is used to encourage a 'positive' review. |
| 19:17 | edcba | we can give them bitcoins... |
| 19:18 | edcba | but yes seriously it could be a good way to promote bitcoin |
| 19:18 | edcba | 'good' = efficient :) |
| 19:19 | kermit | from my 20 hours of reviewing, i'm more worried about it getting popular faster than it can be maintained |
| 19:20 | edcba | lol |
| 19:20 | edcba | yes official bitcoin client is hard to understand |
| 19:21 | kermit | its far more important that its robust than easy to use, if its robust, it'll get used, others might even write their own UIs |
| 19:22 | kermit | there's extreemly large demand for this niche, it does everythin gold does, *and* its anonymous *and* you can backup your "gold".. it sells itself. |
| 19:22 | theymos | Bitcoin is certainly far from 1.0. Probably tons of security flaws yet to be discovered. Satoshi has been very fast with fixing them, though. |
| 19:23 | nanotube | yea, it's probably best to let the adoption curve run its course, until we get to some 'stability' |
| 19:23 | nanotube | kermit: hehe, 'reviewing' as in... sending me a bunch of no-fee microtransactions and almost borking my wallet? :) |
| 19:25 | kermit | nanotube: yeah |
| 19:25 | nanotube | heh |
| 19:28 | kermit | nanotube: i had to know if everyone was serious or if its just an acedemic project for someones PhD |
| 19:29 | nanotube | kermit: heh yea... well when you have an exchange rate to real currencies... you can be pretty sure it's serious. |
| 19:29 | kermit | nanotube: well, or really stupid ;) hehe |
| 19:29 | theymos | kermit: If you look at the initial public announcement of Bitcoin, it sounds like it's just some experiment that was never meant to get big. |
| 19:29 | kermit | theymos: i think thast why wikipedia deleted it |
| 19:30 | nanotube | kermit: hehe or that :) |
| 19:41 | grondilu | Should I worry if one of my received btc keeps in '0/unconfirmed' status ? |
| 19:43 | theymos | grondilu: If it stays for more than 30 minutes or so, there's probably something wrong with it and it won't ever clear. (Maybe someone is abusing the microtransaction bug?) |
| 19:43 | grondilu | I had 82839 blocks though |
| 19:44 | grondilu | oh I'm in '3/unconfirmed' now. I guess it's my connection being poor. |
| 19:56 | kermit | is there a command line too to look at these berkeley db files? like sqlite3 for sqlite3 files |
| 19:56 | kermit | i'm very curious to see in what denominations my coins are |
| 19:56 | theymos | No. You can use bitcointools to get that info, though. |
| 19:58 | kermit | theymos: oh, thanks |
| 19:59 | nanotube | where does bitcointools live? |
| 19:59 | theymos | nanotube: http://github.com/gavinandresen/bitcointools |
| 20:13 | puddinpop | Does anyonw know what khash/s ArtForz was getting on 5770s? |
| 20:16 | kermit | puddinpop: (2010-09-28 17:24:11) ArtForz: 5770s are a bit worse for power/hash, about 1.3Mhps/W |
| 20:16 | kermit | you'll have to look up ho many watts they are |
| 20:16 | Keefe | which varies |
| 20:16 | kermit | puddinpop: you'd know.. has anyone got any CUDA working in linux? |
| 20:17 | puddinpop | I haven't heard of anyone at all using the CUDA code that was released |
| 20:18 | puddinpop | Are you trying to get it working |
| 20:18 | kermit | puddinpop: i'm still trying to get any idea if i could even begin to try to get it working.. |
| 20:19 | kermit | considering i havent heard of CUDA until yesterday, and i dont own an nvidia card or a desktop PC, i have a ways to go. but i know C! |
| 20:19 | kermit | if it can be done in linux, i can do it, i can do anyhting in linux. |
| 20:20 | puddinpop | Without a CUDA enabled device, it's not going to work |
| 20:20 | puddinpop | But you could probably compile it, but it would do you no good. |
| 20:21 | kermit | if i could compile it, i'd find a card to try it |
| 20:22 | kermit | has it been done though? |
| 20:22 | puddinpop | Well can you compile the vanilla client? |
| 20:22 | kermit | yes |
