Hi,
you give me good tips. Thank you!
I will test it soon, but now I have another question:
Is it possible to start the sync with an another bitcoin program, like multibit, under windows 7?
I store before syncing my wallet from the mac os in the multibit file folder. And I store the bootstrap-file (23 GB) which I downloaded with torrent software.
Is this example possible?
thanks and
best regards
No, Multibit is not a full client and does not need the blockchain available locally. |
|
|
|
I'm usually not that blunt, but this has been tried before and it went to shit: https://bitcointalk.org/index.php?topic=77469.msg861305#msg861305Basically you are betting that you will be offsetting your initial cost of installing the plant against electricity cost of your mining competitors. Thing is, the major farms are getting such low electricity as they buy in bulk, they are way ahead of you. Basic example: You: 100'000 for a smallish plant, completed in x weeks, months. Your competition: With 100'000 they can get electricity for 230kW for about a year at 5 cents. Your competition is mining _now_ whilst you need to build that plant. Please crunch your numbers before attempting this. Include network difficulty and exchange rate numbers too. Also, internet speed is not that important for mining. The stratum protocol uses little bandwith. Depending on distance and topography you also could use a wifi antenna to reach several kilometers. |
|
|
|
Sounds good, but how would I get the QR codes off of the offline computer and onto the online computer. I can generate them on the offline computer and scan them into my phone, but how do I get them to the online computer without using a wand or some other USB interface I'm trying to avoid?
Built-in webcam on the online PC? Reads the QR code from the offline PC and you always can double check and compare the output the software provides (QtQR for Linux, for example). But depending on tx size you'll end up scanning several QR codes. (etotheipi's post) |
|
|
|
This is what I really don't *get* when Armory (in particular) talk about offline signing for "cold storage" - it always seems as though they are trying to solve problems for "idiots" (but they seem to forget that "idiots and ingenious" and are going to lose their BTC no matter which software they use - and yes I don't recommend CIYAM Safe for "idiots"). Why on earth would I have "40 donations" to a "cold storage address" that should never have never published.  CIYAM Safe works perfectly on the assumption that you "know what you are doing" and you don't go "publishing your cold storage addresses publicly" (so there should only be 1 UTXO to deal with every time which works perfectly with just QR codes - one to receive the unsigned raw tx and one to send the signed raw tx). Because like you said the other day, Armory is a wallet, that offers the possibility to keep the private keys cold. It's not a single key cold storage. Doesn't matter if it's 40 tx to one address or 40 different addresses. Say you have armoryd (watch-only) giving out addresses to customers. Later you want to spend from those, via the offline computer. There's the problem there. |
|
|
|
[...]
You can still have watch only addresses, tap the key plus button in accounts tab, select advanced, scan to import.
[...]
Yeah, but how about HD watch only? Sort of what Trezor does when you unplug the device. You still can request more receiving addresses as you please, but to spend you need to plug it back in. |
|
|
|
|
You really think OP's interest was purely academical?
|
|
|
|
We wanted to ask the community if they have had any dealings with LakeBTC.com. They have extremely large volume for a new exchange and I don't know a single trader (and i know a few) that have used them. https://www.lakebtc.com/api_v1/tickerJust wanted to put the feelers out before integrating them into our system, it seems they paid Coindesk to integrate them into their index or have some other deal. Note: Yes they do have fees for trades. How come you are so cautious when you still have BTC China listed? How many traders do you know on that 0% fee exchange? |
|
|
|
Mark, thanks. I might have to buy on BTC-e. Do they have limits? [...]
No limits on btc-e. They are the shady BTC supermarket, woot wooot! Although you'll rip through the order book considerably with a market buy of that magnitude, offsetting the general lower price on that exchange. |
|
|
|
[...] say $2000 for 12 months at 2TH/s. [...] Since the days of GLBSE, this is called a mining bond or turd. With ever rising difficulty you won't make profit. So, you have to bet on the BTC exchange rate. With this model and if you think BTC will rise, you'd be better off getting BTCs directly. [...] In the second model, you purchase some amount of hashing power that mines for you (say 2TH/s at 0.001135BTC per GH/s), but you are charged daily/monthly maintenance fees. [...]
ckolivas' and my earlier post relate to that. Bottom line: If you can mine below the fees (and hidden fees) of the operators of those sites (and you have to trust them), mine yourself, you'll be better off. |
|
|
|
|
Aye, risk, and markets not agreeing with a programmer's idea. As a former user of "auto-traded-forex" I can relate.
|
|
|
|
|
Some thoughts from using the HD version on main-net for a bit:
Previously, as a merchant, I could have used Mycelium with a watch-only address at the shop without worrying employees would be able to get to the BTCs. I don't see that functionality now, unless I'm missing something. I think it is possible, as I have seen a "address generator thingie from a public master seed" website somewhere (probably the Trezor thread). Pardon the non-techie speak.
Synchronising the wallet seems to take a lot longer. Might be (hopefully!) because of the increased user base?
As HD basically means seeds, how can I enter my own dice-derived 24 (for example) word list to use it as an account? I have not yet backup-ed my account, if that makes a difference.
|
|
|
|
|
Everything you put on the "cloud" consider it public information for other people to see.
Yesterday it was nudie shots from the beach, tomorrow it will be wallet.dats. Sure a password will put a timing fuse on it. Considering the majority of passwords in use that fuse won't be that long though. So, no, don't put your encrypted wallet.dat on the cloud. Put it on different types of storage media rather. CD, DVD, different HDDs, USB if you must. Things _you_ control.
|
|
|
|
[...] You can "kick it" to get it going faster by shutting down Bitcoin-Qt and restarting it. [...]
From my experience you also have to delete peers.dat for a successful "kick". |
|
|
|
|
I would contact them now. Seems like they shut it down, but allowed bitcoind to shutdown in time too. syslog will have some info.
|
|
|
|
Compile it my self ? I guess it dosen't worth it then haha , only programming language I know is C# & ASP.NET and Bitcoin core looks like C++ just going to pay the fees  It's not that hard, I don't know much about programming and managed to get it done. |
|
|
|
Sort-of-update, nothing new or resolved, but maybe some more detail/accuracy: I have isolated the Zombie to its own cgminer instance and it returns only this on startup: ERR: Asked to memcpy 0 bytes from usbutils.c _usb_read():
3170
HFA : OP_USB_INIT failed! Operation status 20 (Regulator
programming error) Repeat. I was not able to detect a short on the board. For the good boards, even with fail-over only I still get the: [2014-10-09 16:56:52] HFB hab5: Bad work sequence tail 1633 head 322 devhead 32
2 devtail 1730 sequence 2048
[2014-10-09 16:56:52] HFB 1 failure, disabling!
[2014-10-09 16:56:52] HFB 3 failure, disabling!
[2014-10-09 16:56:53] HFB hab4: Bad work sequence tail 1409 head 1881 devhead 1
881 devtail 1505 sequence 2048
[2014-10-09 16:56:53] HFB hab2: Bad work sequence tail 115 head 726 devhead 726
devtail 239 sequence 2048
[2014-10-09 16:56:53] HFB 0 failure, disabling!
[2014-10-09 16:56:53] HFB 4 failure, disabling! Whilst at the same time in syslog: Oct 9 16:56:52 lubuntu kernel: [171751.096002] cdc_acm 1-4.3:1.0: ttyACM0: USB ACM device
Oct 9 16:56:52 lubuntu kernel: [171751.096370] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device
Oct 9 16:56:53 lubuntu kernel: [171751.618102] cdc_acm 1-4.4:1.0: ttyACM2: USB ACM device
Oct 9 16:56:53 lubuntu kernel: [171751.622705] cdc_acm 1-2.2:1.0: ttyACM3: USB ACM device
This happens roughly once per hour. I'd still be interested to hear what cgminer version fellow miners are running. Not that it will solve the problems above, but maybe get same additional stability. |
|
|
|
Mark, what's wrong with stamp? (It seems the local exchanges are running out because a bunch of people are buying.) Or any other? (BTC-e?) Or are we avoiding doing wire transfers?
Because the price on btc-e is usually the cheapest in the USD market... |
|
|
|
I think a better solution would be to use QR codes to transmit the unsigned/signed TXs between computers (I think this was suggested once or twice above). This would prevent any physical attack to your offline computer and would ensure that nothing that has touched your online computer will ever touch your offline computer
For spending from cold storage, yes. See CIYAM's solution: https://susestudio.com/a/kp8B3G/ciyam-safeFor tx signing, not so easy: [...] Okay, so that gets us back to the original question of "how much data do we have to transfer between online and offline computer?" Unfortunately, the simplest case is not relevant to this discussion: you have to design the protocol around the 99.9'th percentile case: which is the case that someone has an offline donation address that they want to clear out. Let's say they have received 40 donations. So the transaction will have 40 inputs and 2 outputs. The bulk of the data is the supporting transactions which can be anything (transactions created by the donors). Each one itself may have dozens of inputs, and the signatures are necessarily included! Let's assume 30 "standard" supporting transactions, and the other ten have 10 inputs each. - Tx-to-be-signed: 30 inputs (unsigned) of 48 bytes each, and two outputs of 40 bytes each = 1.5 kB
- 30 standard supporting tx: 250 bytes each = 7.5 kB
- Ten larger tx: 180 bytes for each input (signed), so about 2 kB each = 20 kB
So the online computer needs to communicate 30 kB to the offline computer in this case. And the offline computer needs to transfer back 30 signatures, which is, at best, 2 kB at a minimum. The "maximum" a QR code can handle is 3 kB of binary, so that's 10 QR codes from online to offline. 1-2 QR codes the other way. So the protocol should handle 30 kB without causing a lot of pain. If the user has to wait a little bit because of a slow communication rate, that's okay because this case is abnormal and waiting 60s for the transfer isn't the end of the world. But if they can't succeed because it's confusing and they can't figure out how many and which QR codes have been scanned, or which webcam they're supposed to be pointing at which device, and frustrated there are wires everywhere, etc. Then there's a problem... As you can tell, I'm very sensitive to the "convenience" of a given feature. I think the biggest barrier to security is convenience -- users just don't use things that are inconvenient. But I also don't want to sacrifice security, at all, no matter how much work it is for me. Which is why there are so many recommendations here that are great, but don't quite the bill. But I'm pretty sure a solution exists where the user can actually have both, in which case everyone wins  |
|
|
|
|
Show Posts
