1. 0% fee
2. Share out to miners
3. Reliable servers and uptime and professional pool operator with a history of being honest
This combination of things is really only possible for a hopping proxy  I disagree. The only thing Eligius lacks is distributing transaction fees to miners (which I hope to solve before the 25 BTC subsidy drop) |
|
|
|
|
While I think some objective requirements might be handy, I think it would be better to run with a simple "any wallet that's usable for the desired audience" and get more specific on an as-needed basis. Maybe apply the objectivity to certifications instead?
|
|
|
|
0.5.4rc3 is now available from SourceForge, having been verified for integrity by 3 developers using gitian (myself, Pieter Wuille, and Matt Corallo) |
|
|
|
next-test should be compatible with 0.6.0, and has Coin Control
|
|
|
|
bitcoind and Bitcoin-Qt version 0.5.4 release candidate 3 is now available for download from SourceForge: bitcoind version 0.4.5 release candidate 3 is now available for download at: These are bugfix-only releases, plus a few protocol updates. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. PROTOCOL UPDATES- BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
- Support for validating message signatures produced with compressed public keys. (0.5 only)
BUG FIXES- Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown. (Windows 0.5 only)
- Fix broken testnet mining.
- Stop excess inventory relay during initial block download.
- When disconnecting a node, clear the received buffer so that we do not process any already received messages.
- Yet another attempt at implementing "minimize to tray" that works on all operating systems. (0.5 only)
- Fix Bitcoin-Qt notifications under Growl 1.3. (0.5 only)
- Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes. (0.5 only)
- Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
- Fix default filename suffixes in GNOME save dialog. (0.5 only)
- Make the "Send coins" tab use the configured unit type, even on the first attempt. (0.5 only)
- Print detailed wallet loading errors to debug.log when it is corrupt.
- Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
- Workaround for improbable memory access violation.
- Check wallet's minimum version before trying to load it.
- Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows 0.5 only)
- Detail reorganization information better in debug log.
- Use a messagebox to display the error when -server is provided without configuring a RPC password. (0.5 only)
- Testing suite build now honours provided CXXFLAGS.
- Removed an extraneous line-break in mature transaction tooltips.
- Fix some grammatical errors in translation process documentation. (0.5 only)
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Pieter Wuille Wladimir J. van der Laan Gavin Andresen Matt Corallo Philip Kaufmann Alistair Buxton Joel Kaartinen Patrick Schneider Vegard Nossum |
|
|
|
For a while, there has been one key component of Eligius that isn't open source: the coinbaser script. The reason for this is mainly due to the absurd ugliness it has become over time, and I hope to one day rewrite it in a clean way. In the meantime, I stumbled upon a copy of the original coinbaser, before it got so messy. This was from when Eligius was a proportional pool, so I'm not sure how useful it is, but I thought it'd be good to publish it anyway... #!/usr/bin/python
# -*- coding: utf-8 -*-
import jsonrpc
import sqlite3
access = jsonrpc.ServiceProxy('http://bitcoinrpc:password@127.0.0.1:8332')
gs = access.listtransactions('*', 5)
gs = filter(lambda txn: txn['category'] in ('immature', 'generate'), gs)
gs = gs[-2:]
available = 50e8
distribution = {}
def distribute(addr, amount):
global available, distribution
if amount < 1:
return
available -= amount
if addr in distribution:
amount += distribution[addr]
distribution[addr] = amount
# Make sure there's some leftover, so it shows up on listtransactions next time ;)
available -= 1
# Fee for running the pool: 1 base unit for every second :P
distribute('1CT1Wbu5kkQArCkWjHnzKyx6YaPCiFTJdB', gs[1]['time'] - gs[0]['time'])
sql = sqlite3.connect('/home/bitcoinpool/pool/data.sqlite')
sqlc = sql.cursor()
sqlc.execute('select count(username), username from shares where time > ?', (gs[1]['time'],))
shares = sqlc.fetchall()
sqlc.close()
del sqlc
sql.close()
del sql
total_available = available
total_shares = sum(map(lambda share: share[0], shares))
for share_count, share_addr in shares:
if not access.validateaddress(share_addr)['isvalid']:
continue
amount = total_available * share_count // total_shares
distribute(share_addr, amount)
print(len(distribution))
for addr, amount in distribution.iteritems():
print(amount)
print(addr) |
|
|
|
Hi Luke-Jr,
something is wrong with the stats at Eligius. Since Apr 2 it's completely wired.
Also the "submitted shares" count looks wrong. Does Eligius loose shares, or it's just a problem with the stats?
Everything looks fine to me... |
|
|
|
I'd love to see Ars keep running. I don't use Eligius due to the long wait required to reach the payout amount (or at least that's why I stopped using it a long, long time ago, and haven't been back to check if anything changed).
Why does this matter? Do you really need your coins immediately? And it's actually MORE secure since it's impossible for Luke to run off with the coins. Don't suppose it matters too much, but It'd just be a backup pool for me, so it takes forever to get to the payout amount. If you don't mine for over a week, Eligius will payout regardless of amount. |
|
|
|
I'd love to see Ars keep running. I don't use Eligius due to the long wait required to reach the payout amount (or at least that's why I stopped using it a long, long time ago, and haven't been back to check if anything changed). Current minimum payout is about 0.67 BTC. But that's only really there for miners' convenience, so subject to change by popular vote... To be honest I'd rather see Ars back up, even if under new management, than move back to Eligius though, just due to questionable decisions by the owner in the past. I suspect you refer to FUD/slander. |
|
|
|
The pool is dead this morning, with no advance notice at all, the one remaining server seems to have crashed 11 hours ago and no one is awake to re-boot it. It was only about 24 hours ago that we (developers) realized all miners without BIP16 support would likely suffer to 100% orphanage when it became enforced. Given Ars's lack of maintenance, I can't say I'm surprised by the turn of events. It could be worse, though - the server could be giving out worthless work. I'd be happy to take on the task of resurrecting ArsBitcoin, but I'm not a developer and would essentially have to train myself in how to administer it, but I'm a sysadmin in my day job and could probably figure it out. If you're serious about helping maintain the pool, I'd like to know if Burning Toad would be interested in handing over the admin stuff and moving on. I thought it was a fine pool, and I really enjoyed mining here and honestly, I'm too lazy (and busy with my day job) to start a new pool from scratch. The pool is already built and relatively stable and functioned headless for months after BT "retired," so I don't think it would be too much of a headache to kickstart, but perhaps I'm an optimist. FWIW, I run Eligius, the original SMPPS pool. I'm not sure why people used Ars over Eligius, but maybe with a few people could contribute whatever they felt Eligius was lacking in (Eligius is a community pool; any community member can get an account on the webserver to add new services/etc)? While I'd help BT out by patching Ars, I don't intend to get involved with running another pool long-term. |
|
|
|
|
FWIW, I offered to do the update for BurningToad (I want to get the stable backports tested). Haven't heard back yet.
|
|
|
|
My friends, we are gathered here today to morn the loss of Donate@Home, BTC Warp, Arsbitcoin, 50BTC, nmcbit, and Polmine.
As a user of Bitcoin I have the honor to speak here today on behalf of the broader Bitcoin community. The tragic loss of these pools could have been prevented, if they paid any attention to the system that gave them life, a system they claimed to serve. But it was not so, and now they will soon fork from the longest chain and become orphaned. Their past blocks, however, will live on — remembered and celebrated by all nodes for eternity. So, now, for the last time as you mine your final blocks we bid you farewell rugged pools. |
|
|
|
Is it safe to use the 0.6.0 version?, newly released.
Yes |
|
|
|
Or the options kanoi left out... (choose "PGA" if you like these, since it's the same code) cgminer version 2.3.1m - Started: [2012-03-25 20:43:39]
--------------------------------------------------------------------------------
(5s):1878.8 (avg):1856.0 Mh/s | Q:41418 A:107620 R:770 HW:0 E:260% U:26.23/m
TQ: 6 ST: 7 SS: 389 DW: 3386 NB: 546 LW: 247388 GF: 7 RF: 14
Connected to http://au.ozco.in:8331 with LP as user miku.1
Block: 00000a240880dae42eea41dd1b91940a... Started: [11:29:40]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
Radeon 5850: 76.0C 3277RPM | 358.7/358.5Mh/s | A:26060 R:114 HW:0 U: 4.99/m I: 9
Radeon 5870: 69.0C 2898RPM | 367.1/365.7Mh/s | A:26372 R:112 HW:0 U: 5.05/m I: 9
Icarus: | 370.7/366.1Mh/s | A:27565 R:273 HW:0 U: 5.28/m
BF Single: 64.1C | 504.1/765.6Mh/s | A:27625 R:271 HW:0 U: 5.29/m
--------------------------------------------------------------------------------
[2012-03-29 11:39:22] Accepted 00000000.df0f50fd.43d06b28 Icarus thread 4 pool 0
[2012-03-29 11:39:24] Accepted 00000000.a7607fe8.9e9ac7de BF Single thread 5 pool 0
[2012-03-29 11:39:27] Accepted 00000000.0e7a8c29.192f6ff1 BF Single thread 5 pool 0
cgminer version 2.3.1m - Started: [2012-03-25 20:43:39]
--------------------------------------------------------------------------------
(5s):1878.8 (avg):1856.0 Mh/s | Q:41418 A:107620 R:770 HW:0 E:260% U:26.23/m
TQ: 6 ST: 7 SS: 389 DW: 3386 NB: 546 LW: 247388 GF: 7 RF: 14
Connected to http://au.ozco.in:8331 with LP as user miku.1
Block: 00000a240880dae42eea41dd1b91940a... Started: [11:29:40]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
opencl: 76.0C 3277RPM | 358.7/358.5Mh/s | A:26060 R:114 HW:0 U: 4.99/m I: 9
opencl: 69.0C 2898RPM | 367.1/365.7Mh/s | A:26372 R:112 HW:0 U: 5.05/m I: 9
icarus: | 370.7/366.1Mh/s | A:27565 R:273 HW:0 U: 5.28/m
bitforce: 64.1C | 504.1/765.6Mh/s | A:27625 R:271 HW:0 U: 5.29/m
--------------------------------------------------------------------------------
[2012-03-29 11:39:22] Accepted 00000000.df0f50fd.43d06b28 icarus thread 4 pool 0
[2012-03-29 11:39:24] Accepted 00000000.a7607fe8.9e9ac7de bitforce thread 5 pool 0
[2012-03-29 11:39:27] Accepted 00000000.0e7a8c29.192f6ff1 bitforce thread 5 pool 0
cgminer version 2.3.1m - Started: [2012-03-25 20:43:39]
--------------------------------------------------------------------------------
(5s):1878.8 (avg):1856.0 Mh/s | Q:41418 A:107620 R:770 HW:0 E:260% U:26.23/m
TQ: 6 ST: 7 SS: 389 DW: 3386 NB: 546 LW: 247388 GF: 7 RF: 14
Connected to http://au.ozco.in:8331 with LP as user miku.1
Block: 00000a240880dae42eea41dd1b91940a... Started: [11:29:40]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
OCL 0: 76.0C 3277RPM | 358.7/358.5Mh/s | A:26060 R:114 HW:0 U: 4.99/m I: 9
OCL 1: 69.0C 2898RPM | 367.1/365.7Mh/s | A:26372 R:112 HW:0 U: 5.05/m I: 9
ICA 0: | 370.7/366.1Mh/s | A:27565 R:273 HW:0 U: 5.28/m
BFL 0: 64.1C | 504.1/765.6Mh/s | A:27625 R:271 HW:0 U: 5.29/m
--------------------------------------------------------------------------------
[2012-03-29 11:39:22] Accepted 00000000.df0f50fd.43d06b28 ICA 0 thread 4 pool 0
[2012-03-29 11:39:24] Accepted 00000000.a7607fe8.9e9ac7de BFL 0 thread 5 pool 0
[2012-03-29 11:39:27] Accepted 00000000.0e7a8c29.192f6ff1 BFL 0 thread 5 pool 0 |
|
|
|
bitcoind and Bitcoin-Qt version 0.5.4 release candidate 2 is now available for download at: bitcoind version 0.4.5 release candidate 2 is now available for download at: These are bugfix-only releases, plus protocol support for BIP 16. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. PROTOCOL UPDATES- BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
BUG FIXES- Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown. (Windows 0.5.4 only)
- Fix broken testnet mining.
- Stop excess inventory relay during initial block download.
- When disconnecting a node, clear the received buffer so that we do not process any already received messages.
- Yet another attempt at implementing "minimize to tray" that works on all operating systems. (0.5.4 only)
- Fix default filename suffixes in GNOME save dialog. (0.5.4 only)
- Make the "Send coins" tab use the configured unit type, even on the first attempt. (0.5.4 only)
- Print detailed wallet loading errors to debug.log when it is corrupt.
- Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
- Workaround for improbable memory access violation.
- Check wallet's minimum version before trying to load it.
- Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows 0.5.4 only)
- Detail reorganization information better in debug log.
- Fix some grammatical errors in translation process documentation. (0.5.4 only)
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Gavin Andresen Wladimir J. van der Laan Pieter Wuille Matt Corallo Joel Kaartinen Alistair Buxton |
|
|
|
My first thought is that the protocol could be modified so that the fee data is added to block (coinbase?). That way the client can look at the last x blocks and get an estimate of the fees the network is requiring. That combined with the number of pending tx and their included fees would allow the client to make educated guesses on confirmation times. That wouldn't allow miners to change fees quickly. IMO, a better solution is to push a URI and signing pubkeyhash into the coinbase... then have a simple (signed) script at the URI that calculates the fee required for a given txn. |
|
|
|
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting). Possible, but might not be simple to do in bitcoind. |
|
|
|
|
Show Posts
