How can we open a new account to buy shares?
There are no accounts anymore. Find someone who is willing to sell you a share. Agree on a price. Both of you send the signed transaction details to LabRat or grnbrg as described earlier in this thread. |
|
|
|
I know it annoys you to have to read this thread, but you'll find that answers to most of your questions are here if you look.
If you know, why don't u do something about it? What exactly do you want me to do about it? There was a fee only for the October 15th dividend payment. It was per shareholder and not per share because that's what LabRat decided to do (dictator get's to make the rules).
And you think asking 1800 bucks to pay some dividends is normal? Even for a dictactor  ? No, I don't think it was reasonable, and I said as much in this thread a few pages ago  I still have no power to make LabRat agree with me. |
|
|
|
I don't get it.. Was a fee charged or not??
If it was why the hell so much? And indeed don't say because he worked a few hours.. I don't recall an hourly wage being part of the LabRat plan..
Also, why a fee per person and not simply a fee per share? I can understand that the true costs from dividend payment (transaction fees and such) but those should be on a per share basis not on a per person basis! If anyone should be paying fees it should be the people entering addresses in the btc address field on bitfunder.
Lastly will trading on Bitfunder be enabled again in the future? Or will LabRat move to another exchange? Why don't u just unfreeze it untill 1st of December?
I know it annoys you to have to read this thread, but you'll find that answers to most of your questions are here if you look. There was a fee only for the October 15th dividend payment. It was per shareholder and not per share because that's what LabRat decided to do (dictator get's to make the rules). There was no fee in yesterday's dividend payment. LabRatMining is effectively no longer available on BitFunder. The asset is frozen and in the process of being delisted. Trading is now only via these forums and must be coordinated with either LabRat directly or with grnbrg. Might things be different in the future? Maybe, but no specific plans have been announced. |
|
|
|
can anyone help me out please,I am using cg miner ,I want to split my hashing asic power in two different mining pool but in one pool it will be 1 GHz and other pool will have the rest of the hashing power,is there any way do to do this.
Thanks.
Yes, you can do this. Read the README document. Search for the section 'QUOTAS'. https://github.com/ckolivas/cgminer/blob/master/README |
|
|
|
So... i need to resend the mail with signed message ?
I send it already and LabRat confirmed it.
I don't want my dividends "rolled over to the following week."
Yes, send the message again. It's easy, and it does no harm. |
|
|
|
Yeah, I agree that it'd be nice to see Jupiters able to hash properly on P2Pool.
Th 10s LP delay makes p2pool mining with KFC a bad move until they work around that. It's 30s now, but your point is still valid. |
|
|
|
In addition to that math (disclosed hashrate projects and difficulty increases) there are big fundamental changes that make people feel different about the potential:
1) people less than 20 shares no longer receive dividends. that is temporary, but such a decision caused a large loss of confidence in management. The shares are worthless without reliable dividends.
2) everyone else has to pay a new fee of a minimum 0.025 per account, perhaps as much as 0.075 per account. again temporary, but investors think it is outrageous and no longer want to be a part of it.
3) transaction fees now have to paid for by investors, and are projected to be 0.0005 per account per week. Small, but investors are losing faith.
Blowing a lot of this out of proportion. Last week was THE ONLY week you'll see a 0.025 fee, and BTC0.0005 is about $0.07. If you think 7 cents on a transaction up to ~$1000 (approx what the highest bondholder was paid last week) is high. Go back to PayPal. EXACTLY! 7 cents on a transaction of 17 cents is insane (a single share)! Is the official policy of LRM that investors only count if you have >$1000 invested? If so, are there plans to merge shares to reduce dust payments? Another option, see: Another thing nastyfans does that could be good to emulate: dividends are paid out once a week in one transaction with minimal transaction fees, essentially shared by everyone. Charging every account .0005 for transaction fees is ridiculous when you can make a single transaction with fees a few times bigger than that. Example: https://blockchain.info/tx/7c4d0999406c28ca71f67bd6c6b0d73ba75f43a565513b5d54ffe0ce480c7cb1total fees for 20,000 "shares" and smaller dividends than LRM: 0.0035 BTC. I don't see how .0005 per account per week is at all reasonable when others are doing 0.00000018 per share per week (for a similar number of shares as LRM). Why not use Iputs.io for off block transactions. Micropayments with zero fees. WeExchange was enough of a pain. Let's not get another middle man involved. There is no reason that every individual dividend recipient needs to worry about the 0.0005 transaction fee. If dividend payments are not using multi-recipient transactions (where 100s of payments can go out in a single transaction with a single transaction fee), then you're doing it wrong. LabRat, if you want to do it wrong, more power too you, but you should pay for that yourself, since there is an viable and easy alternative that doesn't have the same cost. ' sendmany' transactions have been standard operating procedure for a long time. Get on board, please. |
|
|
|
|
I think the reasons have been well expressed (both calmly not-so-calmly) in the thread so far. I'll just say I agree that the fee was unreasonable. You really ought to reimburse it.
And going forward, the bitcoin network fee really ought to be paid out of your own pocket (correction: out of the 25% you keep each week). Once automated, you really should be using sendmany and therefore should not have to pay 0.0005 per person, but rather just pay fees on a handful of multi-person transactions.
Finally, can you please be crystal clear on your plans for the asset and bitfunder? Are you going to delist it? I need to know if I have to go through the verification process prior to November 1st just to continue to hold my shares?
|
|
|
|
ahh, I see, so when I send 1 bitcoin from an address that has 25 coins, it will send the 24 coins back to a newly generated address, is that what your saying? Damn, what wallet do you recommend? I dont mind making backups, but it would be nice not to HAVE to back the address up...
Yes, that is what I mean. I use and prefer bitcoin-qt (bitcoind, actually, with a custom web frontend). Backing things up is really not a big deal. It's a one time task that I had to setup. My backup script copies my wallet to my dropbox every half hour automatically, and my offsite backup software automatically backs that dropbox folder up as well. I just put this in my crontab: */30 * * * * /usr/local/bin/bitcoind backupwallet /Volumes/Data/Dropbox/Backups/wallet.dat
Set it and forget it... |
|
|
|
Tell m if Im wrong, But from what I understand once I have made a backup of my wallet and I dont add any more addresses to it, I dont have to continue to make backups every time I receive or send coins, correct? Its only if i add an address that I have to do another back up. Or am I wrong?
Yes, correct. grnbrg. If you are using bitcoin-qt, this is wrong. Every time you send BTC, a new address is quietly used behind the scenes to receive the change from your transaction. You don't need to backup your wallet.dat every time you send BTC, because bitcoin-qt pre-creates a bunch of keys for this purpose, but when it runs out of pre-created keys, it will automatically create more and those new ones won't be in your old backups. tl;dr: backup your wallet.dat regularly, not just once. Create a cron job or a scheduled task to back it up to a Dropbox account or something once a day and you'll be fine unless you do 100s of transactions per day. |
|
|
|
Once it's removed from bitfunder will there be any way to trade? I'd like to buy more as I can. I'd been buying one more every week or two depending on dividends and price. Are those days over until you find another way to trade?
This can be traded the same way that AsicMiner was traded routinely in the past... the auction forum here: https://bitcointalk.org/index.php?board=73.0 |
|
|
|
So what you are saying is that what other pools or miners are doing, regardless of their hash rate or how many blocks they find, has no bearing on a specific pool's luck? even though everytime someone else finds a block you effectively have to start over? I have trouble wrapping my mind around that, but then, i did fail probability and statistics. Correct. Nothing else on the network impacts your expected rate of block solving at a given difficulty. The only minor impact is that when the network is going faster, the odds of an orphaned block are higher (higher block rate = more chance of two blocks at the same time), but those are still a very rare case, and on BTC Guild you're paid for orphans so they wouldn't show any reduction in luck. I need to think on this. thanks for being patient with me. It might help to remember that there is no "starting over" and no concept of "progress" towards finding a block. Each hash attempted represents an independent attempt to find a solution, and the next hash you try is just as likely (or unlikely), based on the difficulty, to find a block as the last hash you tried. I suppose you could say that when mining at 1GH/s, you are "starting over" 1 billion times per second |
|
|
|
with the 3.4.3 version my accepted and rejected shares count is wrong.
Ex. in the log i see 5 or 6 shares, while the program report A:1920 R:230 ecc.ecc.
i see that the api works fine
now, i'm using the 3.1.1 version and works fine.
Because of vardiff, the UI now shows "Accepted Difficulty" instead of simple count of accepted shares (because not all shares are equal in a vardiff world). So if you find a share with difficulty 16, "A" will increase by 16 and not by 1. |
|
|
|
Over the past several months, several people have asked me if the source code for my custom mining dashboard was available. My answer was that I was in the process of rewriting it and that I'd be willing to share the code once that was done. Well, it's done enough that I just put it on GitHub for anyone that is interested: https://github.com/ervwalter/bitcoin-commandWhat is it? - It shows stats on your mining operation and on individual devices
- It is also a web frontend to bitcoin-qt or bitcoind allowing you to remotely manage your BTC (over SSL with strong wallet passphrases, of course)
Important Note: This is not a turnkey application, and is not prepackaged such that you can just install it and be up and running. If you would like to use it, you will almost certainly need to have an understanding of the technologies involved and you'll need to be comfortable reading and editing the source code to make things work for your specific setup. The technologies involved are all open source and relatively easy to get up and running on Linux or OS X. I wrote up the full details in two blog posts (one about the functionality, another about how the code is organized). If you are interested, you should definitely read these: Bitcoin Command: A Mining & Wallet Management Web AppBitcoin Command: Fun With AngularJS, NodeJS, and MongoDB     Out of the box, it assumes you are using cgminer as your miner. It might work with bfgminer, but I have never tried it. Sometime before my BitFury hardware arrives, I plan to also enhance slush's stratum proxy to feed data to the dashboard as well. If anyone runs into any issues with this or has any questions, I'm happy to try to answer them (as long as the question is not, "Can you help me install this?")... |
|
|
|
It appears he is done with the updates/upgrades, but to be sure I split the hardware between BTCGuild (I didn't want to do that) and James' pool.
Until the situation changes, can you please share what the Lab_Rat user ID is on btcguild (as shown on this page: http://www.btcguild.com/index.php?page=rankings) so that we have some transparency on hashrate? Unless most of the current hardware is pointed at BTCGuild it won't show up on the leaders board I'm afraid. Although not ideal, transparency does at least come once a week in the form of dividends... Dividends are not transparency. Transparency is being able to independently confirm the hashrate throughout the week to validate that the dividends match approx what they should have been. And with only 0.7 TH/s pointed at James' pool at the moment, there should be 3+ TH/s on btcguild (unless there is a third pool in play) which should be enough for it to appear on the leader board. That will be even more likely to happen if additional hash power gets added soon. |
|
|
|
It appears he is done with the updates/upgrades, but to be sure I split the hardware between BTCGuild (I didn't want to do that) and James' pool.
Until the situation changes, can you please share what the Lab_Rat user ID is on btcguild (as shown on this page: http://www.btcguild.com/index.php?page=rankings) so that we have some transparency on hashrate? |
|
|
|
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found. That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API. Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares. When solo mining, the job difficulty is just = the the network difficulty. So a share = a block, and the counter is going to increment by the difficulty of each block found. I still don't think that is a bug. ckolivas can clarify, but I don't think there was an intention of a "block found counter". You're in a somewhat unique situation, and if you need a block found counter, I would suggest using the API (in which shares = blocks, when solo mining). |
|
|
|
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found. That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API. |
|
|
|
Well, until Lab_Rat comes up with something of his own... http://labratstats.herokuapp.com/Note, the pool is calculating this hashrate based on submitted shares, so it is subject to good/bad luck of the miner and therefore fluctuates a bit. |
|
|
|
|
Hey, Andreas,
This is an outstanding client. I really appreciate the work you've put into it (not to mention the attention to detail and good UI), so thanks!
I have a bunch of my coins stored offline on paper wallets. However, I am not as dilligent at using them as I should be because it's still kind of a hassle to use them. I can imagine it being much more convenient if private key sweeping or something similar was added to the this client though. There is something awesome about being able to use the camera on my phone with QR codes vs having to mess with entering private keys manually on a desktop computer (or even using a web cam on a desktop/laptop computer).
What I imagine doing is printing out a stack of paper wallets (from an offline copy of bitaddress.org). I would then keep the bulk of my balance in one of the public keys. It's already easy to send coins to a paper wallet by scanning the public key QR code. When I need to spend some of that offline balance, I'd love to be able to scan the private key, spend what I need to spend, and have the left over change end up on a new paper wallet address (the one I just spent is, in theory, no longer safe since the private key has been exposed to my phone).
Possible workflows would be:
1. Scan the private key and sweep all funds into the live android wallet with a transaction. (this is new UI)
2. Spend some coins. (this is using the existing UI)
3. Manually send the bulk of the remaining balance to a new paper wallet public key. I wouldn't send my entire wallet balance to the paper wallet, because I do keep a few coins on the phone just for easy access on short notice. (this is using the existing UI)
Alternatively, but perhaps more complicated (from a UI perspective) by more useful would be a paper wallet transaction builder:
1. Scan the private key. Android wallet finds the unspent outputs for that private key.
2. Scan the recipient address (i.e. where I want to send coins to). Alternatively, just choose to send the coins to android wallet.
3. Choose how much to send
4. Scan a "change address" for any left over coins (e.g. a virgin paper wallet)
This way, I can have 100 BTC in a paper wallet, send 5 BTC to someone and have the remaining 95 BTC end up directly in a new paper wallet. Or I could selectively "transfer" only 5 BTC of my 100 BTC into my online wallet for future spending as needed while keeping the remaining safely offline.
Anyway, I read somewhere that you use paper wallets, yourself, and I was curious if you had thought of implementing anything in Android Wallet like this to make it easier.
|
|
|
|
|
Show Posts
