- Eligius belongs under Company, Service, Start-Up, and Pool
first I have no clue what this is ? Seriously? Something like this should be moderated by someone who knows something about the Bitcoin community, I'd think.  Eligius is the 5th biggest pool, and one of the oldest. And no this isn't one big troll "thing" I'm tried to deal with vandalism as bests as I could its just the nature of having it "open" like this. Sorry  Well, that was why I had suggested it needed moderation... :p |
|
|
|
Time to VOTE! get to it! You forgot to de-vandalize it... haha hey I can remove you if you want - Eligius belongs under Company, Service, Start-Up, and Pool
- Luke-Jr belongs under Person and Developer
- Tonal Bitcoin belongs under Project
- Ars is basically dead, so probably shouldn't be an option for Pool
If this whole thing is a big troll, I suggest donors and sponsors should demand their money back. |
|
|
|
Time to VOTE! get to it! You forgot to de-vandalize it... |
|
|
|
|
AFAIK this is simply "someone needs to implement it"
|
|
|
|
|
This spreadsheet needs some moderation. Too many vandals.
|
|
|
|
WTF? I just logged in today to find I've been mining namecoins without my consent? I don't want namecoins. :/ What makes you think that? If you don't want Namecoins, don't register for them, and you won't get them. Simple. (I didn't really think I needed to answer this...) I know that many people don't know how merged mining works and may think that it's somehow makes their bitcoin rewards lower, but I can also imagine people that don't like Namecoin project at all and don't want to support it  Myself included (not liking Namecoin), but that doesn't mean I'm going to be a jerk about it.  |
|
|
|
WTF? I just logged in today to find I've been mining namecoins without my consent? I don't want namecoins. :/ What makes you think that? If you don't want Namecoins, don't register for them, and you won't get them. Simple. (I didn't really think I needed to answer this...) |
|
|
|
I see that the "Full URL Support in bitcoin-qt" pull isn't coming, what's wrong with it?
0.6 merging isn't done. At least coinbaser and signmessage-GUI were accepted for 0.6 before it began, and they're still pending. There's some OP_EVAL issues that need to be sorted out as well. |
|
|
|
Bump
Garbage doesn't need bumping. |
|
|
|
It's also a bit strange that the filesizes are so drastically different. Did they really re-write the whole thing for a graphical change? Mac OSX 0.4.1 is 4.08MB and 0.5.1 is 13.8MB.
Windows version also doubled in size, yet the Linux version shrunk a little.
Qt apps are bloated, so that's not surprise for me. But the memory consumption are exactly the same or maybe a little bit less for Qt version. No, Qt apps are not bloated: as he noted, the actual application got smaller. But Windows and Mac omit the standard Qt libraries, so Bitcoin-Qt includes them for convenience. |
|
|
|
If anyone wants to send some Christmas donations my way... 13nPeoTJjaRvtXudfe3nrBFrA7BhPiv8c9 |
|
|
|
|
If anyone wants to maintain wxBitcoin, get in touch with me on IRC and I can help you get git setup for it correctly.
|
|
|
|
Its not such a big gamble . As long as you define a low enough Auto payout or manually do it every day.
In the worse case you could lose a day ( maybe 2 ) of mining if the pools collapses before you get your payout. There is no different here as far as SMPPS is involved. Raw PPS has an additional risk of "pool died, nobody got paid" because it promises more than it might be able to provide, but SMPPS never promises more than it has, so its balances are guaranteed to be available so long as someone doesn't steal it (eg, operator or some cracks the pool). Eligius intentionally doesn't keep a balance, by paying out as soon as you have accured a reasonable amount, so there is much less risk than other pools. |
|
|
|
Some older versions used that time until it was confirmed, and then changed the timestamp to the block time. This caused listtransactions to change order.
List transactions - the balance sheet in the local client? I meant the JSON-RPC method, which software kindof needs to have in order. Could the local sent timestamp or autoincremented index be stored separately from the block timestamps? I don't care what the GUIs do. They can display the block timestamp, while sorting by the "list-canonical timestamp" suggested in this thread... |
|
|
|
Current block estimate not updating  Try reading the notice? |
|
|
|
A little off topic, but when did the transaction dates stop being shown from the block timestamp and started being the timestamp at which the block was received? This bugs me because I do mental averages of generation, and only start the client every now and then, which then proceeds to download the blockchain pinning all new transactions under more or less the same date and time, i.e. now.
This still happens with 0.5.1, don't know if a bug or feature, it started somewhere on the 0.4 series and I always forget to report...
Other than that, looks very stable to me, but I've only done 'normal' usage, no real hard core testing.
For me this also seems like a bug. If this should be a feature, at least it should be possible to display both sorts of dates. |
|
|
|
Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?
This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested. The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet. Is there a thread discussing these security risks? It's simply that you're inputting a private key from an external source, when the mindset most users will have is that their balance is theirs. ie, the risk that someone else somewhere has a copy of the private key. |
|
|
|
Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?
This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested. The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet. |
|
|
|
|
Also tagged are 0.4.2rc1 (bitcoind only) and 0.5.0.1rc2 (bitcoind and Bitcoin-Qt). Note that I do not intend to maintain 0.5.0.x very long.
|
|
|
|
|
Show Posts
