I remember when I said that my break-even point for mining was $7. And yet, here I am, still mining... Using winter electricity instead of extra electricity for A/C during the summer definitely helped keep me going though.  |
|
|
|
|
Well, I can tell you both one thing. You're currently losing money.
|
|
|
|
I'm going to CES for a day next week.
I understand Roger Ver (MemoryDealers) is going to be there selling physical bitcoins for cash. Since I had to drop $600 a night just to get a hotel room there - nothing on the LV strip decent available for under $400 - it's not like people there are going to be poor, nor few in numbers, nor (it being CES) will they be techno noobs.
I anticipate bringing tons of them to keep them stocked up just in case. I will probably bring several dozen 1000 BTC bars, and numerous 25 and 100 BTC items. Who knows what'll sell, but everything that sells is going to see an offsetting transaction on MtGox.
You're going to wait to fill the bars and coins until they are sold, I presume? And you don't have that much BTC, so you'll buy BTC for each one that sells? EDIT: Just bought back in with the proceeds from my last month and a half of mining that I had been selling. Sucks to effectively get half of the Bitcoins I sold, but I am very bearish at the moment. We'll see... I have 50k of mtgox USD locked and loaded, not on the order book anywhere, so I can dispense BTC based on market rates without worrying about my personal BTC or whether the rates will go up or down until then. That's good! That'll buy a decent amount of BTC... at least for now.  |
|
|
|
I'm going to CES for a day next week.
I understand Roger Ver (MemoryDealers) is going to be there selling physical bitcoins for cash. Since I had to drop $600 a night just to get a hotel room there - nothing on the LV strip decent available for under $400 - it's not like people there are going to be poor, nor few in numbers, nor (it being CES) will they be techno noobs.
I anticipate bringing tons of them to keep them stocked up just in case. I will probably bring several dozen 1000 BTC bars, and numerous 25 and 100 BTC items. Who knows what'll sell, but everything that sells is going to see an offsetting transaction on MtGox.
You're going to wait to fill the bars and coins until they are sold, I presume? And you don't have that much BTC, so you'll buy BTC for each one that sells? EDIT: Just bought back in with the proceeds from my last month and a half of mining that I had been selling. Sucks to effectively get half of the Bitcoins I sold, but I am very bearish at the moment. We'll see... |
|
|
|
Bit-pay is going to have a booth at CES (consumer electronic show) in Vegas next week
prepare for lift off
$10 is easy on the horizon
Now, I wonder how many people are holding off on selling their earnings knowing that information? And how well it will supply those new demands when they do decide to dump their holdings? I'm definitely holding off on selling my most recently mined BTC though until some point after the conference. Don't worry, I'll only have 15 or so by then, haha. |
|
|
|
...as though you've suggested that a three-toed Martian leper stole all your hair follicles to build a living string instrument and you want them back. I do rather like that choice of words. |
|
|
|
Guys... Im pretty sure he wants to put it in a water proof box. And sink into a pool of Really cold water
I'm pretty sure not, since he specifically mentions "pure" water. |
|
|
|
Everyone who said no is wrong. Makes me laugh. Especially the people who said no with absolute certainty. |
|
|
|
|
Sweet. How much does something like that cost?
|
|
|
|
It's probably just a few lines of code. They have nearly identical behaviors so it's really not a big deal.
mmap maps regions of address space to files. When you access them the OS faults the underlying file region into memory if necessary. Therefore you do not need 2GB of RAM to load a 2GB file. You do however need 2GB of address space. On a 64 bit system (regardless of how much physical RAM you have) this is not an issue. On 32 bit you're not going to achieve that because most OS' fragment the address space somewhat and indeed typically reserve the top one or two gigs of address space for the kernel.
Well, that is a good point, but then, who is running a 64-bit OS with less than 4GB of ram? Most people only utilize a 64-bit implementation of an OS so they can address 4GB+ of RAM. I bet the percentage of users using less than 4GB of ram on a 64-bit OS would be extremely small, which would render the work of implementing virtual memory into this client rather useless. If it's not a big deal to implement, go for it, but if it's going to take away from development of other features, or bug fixed, etc, I would first do a market study to find out exactly how many people NEED a virtual memory implementation. You know, a cost vs benefit analysis and all of that. |
|
|
|
Bitcoins can be set up to be sold automatically and immediately in MtGox.
Not to hijack this thread.. but i looked all over MTGOX and can't find where to set this up.. Where do you go to turn this on? Or do you have to use the API?
thanks,
Sigg
You just enter a sell order for 10000000 @ $1.00 each (or whatever your rock-bottom-will-not-sell-lower-than-this price is), then it'll automatically sell any coins when they are sent to your account and have 6 confirmations. It won't sell them for $1 though - it'll sell them at whatever the current highest buy offers are. |
|
|
|
I remember those ascending triangles, yes... |
|
|
|
I am optimistic now simply because the price held at $2.50 for so long. Which means, it's not likely to go lower than that. At $2.50/coin, with 7200 coins generated daily, people believe in Bitcoins enough to inject $18,000/day into the system. That's a significant amount of money, and I don't think it's just one person, or just a few people. Pure speculation on my part, but I don't see a system viewed as failed being propped up for this long by this much money by less than a dozen people, and more likely, it is propped up by hundreds. Then, you look at the future. We are now less than a year away from mining rewards being cut in half. As we get closer to that point in time, we will have more and more assurance that the value of Bitcoin has only one way to move, assuming that same $18,000/day injection. I think $2.50 really was the rock bottom. There are too many people who believe in Bitcoin and want, badly, to see it succeed, for it to fail completely. It might forever be a niche item, but that niche will always be there. And so far, no one has come even close to overturning Bitcoins as the go-to product for the niche. This is all just my opinion, of course.  +1 glad to see you back onboard. so you now see the psychological impact of price alone. its self feeding on the way down and causes all sorts of negative sentiment which break us apart. now on the way back up, we can reunite and make Bitcoin the new alternative.  Haha, you've been tracking my sentiments. I did go from optimistic, to pessimistic, and back to optimistic about the long-term future of Bitcoins. Reason being, when I was pessimistic, it was because I believed Bitcoin would always be a niche product. But now, I am beginning to realize that it is enough of a niche to sustain the project, pretty much indefinitely. I don't see how Bitcoin could ever die completely. |
|
|
|
It's an all-or-nothing deal. Either load the whole blockchain into RAM, or don't load any of it. It's too inefficient and pointless to try and use virtual memory.
Very few transactions need to read the entire blockchain. A reasonable blockchain index could be kept in RAM and the entire blockchain mmap'd to virtual memory. As best I can tell, Bitcoin transactions tend to access recent blocks far more often than ancient blocks. The OS virtual memory system should handle that access pattern efficiently. One possible implementation would be an in-memory index mapping a Bitcoin address to the first block in which it appeared. Private key sweep code must only traverse, and possibly fetch from disk, subsequent blocks. With this kind of access pattern, the OS is likely to keep the last several thousand blocks in RAM and rarely fetch extra data from disk. I can see what you mean if an index was created for addresses, but for transactions? What good does a transaction index do when you are looking for transactions to do with specific addresses? Regardless, I can see how an index would make it work. |
|
|
|
I see too much blind optimism. Everyone thinks bitcoins will rise to the moon again.
Remember some points.
1) Bitcoins are as useless now as they ever were
What kind of person wastes time on forums about things they think are fundamentally useless? Psst... also, not all commodities are consumed. Hint: think metals.What metals are not consumed? |
|
|
|
I am optimistic now simply because the price held at $2.50 for so long. Which means, it's not likely to go lower than that. At $2.50/coin, with 7200 coins generated daily, people believe in Bitcoins enough to inject $18,000/day into the system. That's a significant amount of money, and I don't think it's just one person, or just a few people. Pure speculation on my part, but I don't see a system viewed as failed being propped up for this long by this much money by less than a dozen people, and more likely, it is propped up by hundreds. Then, you look at the future. We are now less than a year away from mining rewards being cut in half. As we get closer to that point in time, we will have more and more assurance that the value of Bitcoin has only one way to move, assuming that same $18,000/day injection. I think $2.50 really was the rock bottom. There are too many people who believe in Bitcoin and want, badly, to see it succeed, for it to fail completely. It might forever be a niche item, but that niche will always be there. And so far, no one has come even close to overturning Bitcoins as the go-to product for the niche. This is all just my opinion, of course. |
|
|
|
Uh, using mmap() or similar on Windows would let you access the blockchain through virtual memory, loading it from disk as needed.
Could this resolve your issue ?
That would defeat the purpose of loading the blockchain into RAM in the first place. You'd have to read the entire blockchain from disk every time you did a scan, which wouldn't be any faster than the traditional client. Besides, ram is incredibly cheap these days. You can get an 8GB kit for $32. Well, at least if your system accepts DDR3. If you're still stuck on DDR2, it'll be a bit more expensive. I wouldn't say it defeats the purpose... I do want a disk-based blockchain implementation--making the user wait 10-20s to import/sweep an address isn't the end of the world--some of them won't be able to even use the software if full-RAM is the only option. But the full-RAM implementation does add some kick for the users that don't mind. This is actually why I'm going to make sure both options are there (at least for the adv/dev modes). Well, I wasn't saying it would defeat the purpose of the client, just that it would defeat the purpose of having any amount of the blockchain in RAM to start with. Say the blockchain was 4GB in size, and you loaded it on a system with 2GB of RAM free, and the rest in virtual memory. You'd read 2GB of the blockchain and stick it into RAM. Then, while reading the last 2 GB, you'd be storing the first 2GB back on the hard drive, effectively making a copy of the information that is already there. So you've already spent 1.5 times the amount of time it would take to scan one address, and that's just from the initial software loadup! After that, it would still be just as slow importing/sweeping addresses as it would if you didn't put any of the blockchain into RAM, because as soon as you scan half of the blockchain, that half has to be written to the virtual memory on the HDD, and the other half has to be read from virtual memory on the HDD back into RAM. It's an all-or-nothing deal. Either load the whole blockchain into RAM, or don't load any of it. It's too inefficient and pointless to try and use virtual memory. |
|
|
|
- You need a system with 4GB+ of RAM
Uh, using mmap() or similar on Windows would let you access the blockchain through virtual memory, loading it from disk as needed. Could this resolve your issue ? That would defeat the purpose of loading the blockchain into RAM in the first place. You'd have to read the entire blockchain from disk every time you did a scan, which wouldn't be any faster than the traditional client. Besides, ram is incredibly cheap these days. You can get an 8GB kit for $32. Well, at least if your system accepts DDR3. If you're still stuck on DDR2, it'll be a bit more expensive. |
|
|
|
This is EXACTLY what I needed to be able to move forward with one of my projects.
Two questions:
1) How well does it handle wallets with many thousands of generated addresses? Say, 50-100k addresses in a single wallet file?
2) When do we get a Windows exe?
The blockchain-wallet scanning should be O(log(n)) in the number of addresses in your wallet. If you have the RAM to try it, I'd be interested to see how long it takes to do the scan and collect the balances, but I would guess it's less than 5s. As for the wallet format: there are no arbitrary limits on how big the wallets can be. I have had 500 addresses in one of my wallets before, without problem -- there are no artificial limits. Perhaps you will be able to help me find the breaking point for wallet sizes. I'm having a problem with PyQt and py2exe in Windows. I have a MSVC++ runtime error when trying to install the pywin32 module, which linked but not actually needed by my software. So I can comment out the imports and the software runs fine, but py2exe complains that it needs it in order to make the executables. it's going to take a little bit more work (and maybe switching systems), before I get an executable made. I spontaneously got an exe built once (so I know it works), but for some reason I couldn't repeat it... For now, I still have some dev left before officially making exe's... maybe I shouldn't have posted so soon (remember, releasing next week) But I'll put up build instructions tonight or tomorrow, and plan to have a Windows exe built by next week. For now, I still have some pretty important bugs to quash before I would trust this software with anything but testnet coins... I'm certainly willing to help experiment. I have some wallets that are nearly inaccessible via the Satoshi client because it starts dragging badly after 150k or so addresses. Am curious if this wallet is any better/worse when dealing with those wallet files. Will look forward to the release next week then! If you have to keep all 150k of them in the wallet, you're doing it wrong. I definitely was! Had much better methods of achieving what I wanted with later... uh... methods, but I still need to keep the private keys for these larger wallets and access them in the future. I hope to find a way to convert all of the wallet addresses to an Excel doc or something in the future, as that would make it easier to manage. |
|
|
|
Yes. I am not sure of the exact computational power of the machines I am interested in using. It actually may be a very poor estimation because I am guessing based on petaflop output which, to my knowledge, is more or less irrational.
Regardless, it's a shit-ton of power.
FLOPs are floating point operations. If you can get access to a supercomputer thats any good at flops, it will almost certainly stink when it comes to sha256 hashing (integer). A typical TOP500 supercomputer may have trouble delivering higher hashrates than your typical 3x dual GPU mining rig From what I was told, the machines I am interested in using are often used for sha256 hashing. Unless they have GPU's, it doesn't really matter. P4man is right - you'll get hashes on the order of GH/s, not TH/s. They may often be used for sha256 hashing, but 12 GH/s is quite enough for most sha256 hashing needs. It's just not a whole lot when used for Bitcoin mining. But good luck. I only hope you DON'T have 2 TH/s, because I would hate to see my own miniscule mining profits drop by 20% overnight. Do tell us whether it works out for you though. |
|
|
|
|
Show Posts
