Show Posts
|
Pages: [1] 2 3 4 5 »
|
I'd swap some WATER for BTC at a rate of 1WATER to 2sat (0.00000002BTC), if anyone's interested (I'm offering the BTC).
Good Gawd man -- why?? Just making a market =)
|
|
|
I'd swap some WATER for BTC at a rate of 1WATER to 2sat (0.00000002BTC), if anyone's interested (I'm offering the BTC).
|
|
|
WATER Wallet is disabled AGAIN on Bittrex- what the hell is happening??? I have never known so many problems with a wallet.
Zach/Mindfox - an explanation please??
The wallet is working fine, the only problem is people attacking the network due to the low PoW network hashrate. When the wallet detects an attack, it shows a checkpoint error - the checkpoint is what keeps Bittrex from sending your coins into a black hole or an attacker's wallet. Once PoW is phased out in less than a week, the network will no longer be so easy to attack. Please keep in mind that mining isn't there only to give people rewards - its primary function is to secure the network. Given the extremely low hashrate of the network and the number of attacks that it has experienced, the fact that Bittrex has not yet been emptied out is a testament to Mindfox's professionalism and security-consciousness. Too many developers opt for superficial fixes to make things seem like they're running, only to end up with the entire coin destroyed by thefts from users and exchanges.
|
|
|
As of a few hours ago, I am no longer getting a high rate of orphan blocks.
|
|
|
In order to transition to PoS-only mode, the latest wallet update changed the staking rules. The immediate effect is more transactions trying to stake at the same time, resulting in more orphan blocks - a situation similar to early mining on a PoW coin with low difficulty. This should calm down by itself in the next 4-5 days.
The checkpoint warnings, on the other hand, are due to constant attacks on the WATER network because of its low PoW difficulty. The wallet is actually performing perfectly - it stops creating new transactions when it detects a problem with the blockchain, thus protecting users - and exchanges - from losing coins. Once the network security is improved by transitioning to purely PoS operation, these checkpoint warnings will also become much less frequent.
|
|
|
For those who are having trouble synchronizing their wallets, try closing them for 24 hours and then re-downloading the blockchain. You may be getting banned by legitimate nodes for inadvertently re-broadcasting blocks and transactions form an incorrect chain.
|
|
|
I'm interested in buying some CWC (from the correct fork, of course!). Please PM me with your amount and price.
|
|
|
Buying 1M+DOGE, paying in BTC. PM reasonable offers!
|
|
|
Sold mine to you!
Thanks, Moose, for a smooth trade =) Still open to buying more.
|
|
|
Buying XRP at $1 USD per 50,000 XRP (also payable in BTC). PM me to trade.
|
|
|
I am buying Ripple Credits (XRP) for Bitcoin and USD.
Please PM your offers, amount and price.
If I do not respond within a few hours, the price is likely too high - feel free to send another offer with a lower price.
If you need something other than BTC or USD for your XRP, I will consider it if the price and volume are right.
|
|
|
How do payouts appear in the wallet do they show as mined or from an address? Thank you for your help
They appear as mined (coinbase transaction).
|
|
|
As someone else mentioned in another it is more likely for them to attempt double spends by creating alternative block chains. I recently discovered that the pool I was mining for (ABCPool) was reselling their hashing power. On fundamentals alone I decided to leave the pool and go back to deepbit. I purposely went to deepbit because I think BIP 16 and BIP 17 need more testing before attempting to implement them. I wonder who ultimately is paying this 105-115% PPS and what their true motivations are. I suggest miners take a closer look at their pool to decide whether or not they support the actions of that pool.
Another possibility is that these pools are engaged in laundering stolen bitcoins. Please consider using BitPenny. It uses an open-source client and coinbase transactions to assure miners that their power is not resold or abused by the server, and that all coins are freshly generated. We also believe that BIP 16 and 17 need more testing and are holding off on implementing either of them.
|
|
|
I suppose the same could be said for the default source provided but if the same person where providing source and executables maybe it would be simpler or at least give me less cause for concern. Bitpennyd is a client that is based on bitcoind (the bitcoin daemon), the GUI part applies to bitcoin but not to bitpenny. The executable is provided by us (the same people who provide the source) at https://github.com/ForceMajeure/BitPenny-Client/tree/master/bin/win32I hope that helps a bit.
|
|
|
Askit2, Bitpenny is a daemon and does not support QT. Please see build-msw.txt for dependencies (substituting "bitpennyd" for "bitcoind" where necessary), and use src/makefile.bitpenny.mingw to build. You can also join our IRC channel for live help, or download a Windows binary directly. Good luck, and welcome to BitPenny!
|
|
|
We've solved this issue at BitPenny ( website) by providing an open-source client and setting the difficulty to 8. This keeps the number of submitted shares manageable while allowing users to get latency-free work locally as often as they wish, even with an array of fast GPUs.
|
|
|
UPDATE AVAILABLEBitPenny Client version 0.4.0.1 (2011-12-12) - updated codebase to bitcoin 0.5.1
- gitian build enabled
- built-in block monitor (see sample config)
|
|
|
Recently, I've been trying to find a pool that has the most fair payout system that deters pool hopping. Slush system works ok but it's really bad for people that are not doing this 24/7. Deepbit deters pool hopping but the delayed statistics is annoying. I came across Eligius' Shared Maximum Pay Per Share (SMPPS - http://eligius.st/wiki/index.php/Shared_Maximum_PPS) model. This model works well but I believe there is a flaw. When the pool is running lucky, all is good. But when the pool is running unlucky, there is less incentives for people to join the pool because they know that they will not get their full PPS reward because a part of the earnings will need to be shared with other users that were owed rewards from previous unlucky blocks. This could potentially lead to a vicious cycle where if the difficulty increases and the pool's hashrate does not increase to match, the pool will earn less BTC and would not be able to cover the previous debt. For example, imagine if a SMPPS pool is unlucky and currently running a 100 BTC deficit. Why would I want to join this pool? For every 1 share I contribute, I would have to likely share it with 2 others for the 50 BTC earned. Let's say the next round is an average round. The pool earns 50 BTC, but since the deficit is now 150 BTC, I will only get a third of the payout right away and need to wait for the rest… assuming I will eventually get them. So why not just join a SMPPS pool that is currently lucky? That way, I will get all the PPS rewards that I contribute. I believe this leads to pool hopping not due to long rounds, but due to lucky/unlucky pools. I have a proposal for a better PPS system that I'm calling Recent Shared Maximum PPS or RSMPPS. The idea is simple. It's basically SMPPS, but instead of paying out the reward to all unpaid PPS proportionally, RSMPPS will favor recent blocks. So it will first proportionally pay out the unpaid PPS for the current block (the one that was just found). If there are any remaining rewards, it will pay them out to the next recent block that has unpaid PPS shares. It will keep doing that by paying out unpaid PPS shares from earlier and earlier blocks until all 50 BTC are paid out. If there are any left, it will keep those for the next unlucky round. This system will have no disadvantage for new miners joining the pool, because rewards will be first paid to the people that actually worked on the current block. So there's no debt burden on new users. And old unpaid PPS shares will get paid out if the pool gets lucky enough. With this system, it's possible for the pool to never get lucky enough to pay out really old unpaid shares. I think that's fair. What do people think? Coblee, BitPenny ( website, forum topic) uses the Delayed PPS (CPPSRB - Capped Pay Per Share with Recent Backpay) system which, I believe, accomplishes what you propose.
|
|
|
|