This encoding is designed so that it could replace Base58Check in new data, with the following goals in mind: - Impossible(?) to manipulate without completely changing it
- Clearly identifiable prefix, regardless of data size
- Cheaper to process (simpler and faster code; it's a power-of-two radix)
- Fixed length string for fixed length data
- More unambiguous (removal of chars 'isuvzSVZ')
- Compatible with using seven-segment displays
- Altcoin friendly (16 bit namespace, which can be read without decoding)
Since there are fewer digits and more identifying/signature characters, addresses are longer. This should be less of a problem since ordinary users will hopefully be using addresses less common as the payment protocol becomes more popular. Example Python code (including tests) is at the bottom. I can write up a formal BIP if this seems useful. For example: 160 bits of data, such as current addresses: - 2nc111dhAPE2aUdYAOF88JhLn5jEjbULy4eFe9tyFYFE8
An ordinary P2SH destination, incorporating Greg's "require the hash mid-image to be relayed" concept (256 bits of data): - 2bc511A95e74P13dPb6b5t7yrh12EhC363ayH98n1cFbr3rAHdA49nCcC1G3P71j
The same key in Namecoin: - 2nc5119ttL35HPhc3Hh6aHe2tOhF6rdFtAOE1ahFLt9Ecabhcn5FLea5Le71P56C
The example "puzzle" script from the wiki (arbitrary scripting): - 2bc311d126acCyAnHAjabeUtOHcr7F811j4UYE6ECtOcbcGGn4O9chAt7O7y2LU9ty9cnG4
An alternative for BIP32 extended public keys (560 bits): - 2bc911AcchHheAGFnn9LC6FdF7bOc99APJtcEc46U655JheH6LCr3Y333eFEOtPJ9rj22rEcchHheAG Fnn9LC6FdF7bOc99APJtcEc46U655JheH6LCr3YJCtPYea
An alternative for BIP32 extended private keys (552 bits): - 2bcb11O77GHdP53FH7Jh44OdEh3rLd4eFr2h7c8rGeErELG18yCy9O7L9LednyHJa5hyeAP77GHdP53 FH7Jh44OdEh3rLd4eFr2h7c8rGeErELG18yCyGG5drPF1
c32.py # Digits are chosen to be the least ambiguous
# They all have unique seven-segment glyphs, and cannot be easily confused by humans
digits = '123456789abcdehjnrtyACEFGHJLOPUY'
radix = len(digits)
def encode(v):
if not len(v):
return ''
n = 0
bits = 0
o = []
pad = (len(v) * 8) % 5
if pad:
v = b'\0' + v
v = bytearray(v) # For Python 2.7 compatibility
for i in range(len(v) - 1, -1, -1):
n |= v[i] << bits
bits += 8
while bits >= 5:
o.insert(0, digits[n & 0x1f])
n >>= 5
bits -= 5
if i == 0 and pad:
break
return ''.join(o)
def decode(s):
n = 0
bits = 0
o = bytearray()
for i in range(len(s) - 1, -1, -1):
n |= digits.index(s[i]) << bits
bits += 5
while bits >= 8:
o.insert(0, n & 0xff)
n >>= 8
bits -= 8
return bytes(o)
def test():
from math import ceil
assert '' == encode(b'')
for (i, oc) in (
(1, '8'),
(2, '2'),
(3, 'j'),
(4, '4'),
(5, 'Y'),
(6, '8'),
(7, '2'),
(8, 'j'),
(9, '4'),
):
ol = int(ceil(i * 8 / 5.))
try:
inzero = b'\0' * i
inone = b'\xff' * i
ezero = encode(inzero)
eone = encode(inone)
dzero = decode(ezero)
done = decode(eone)
assert ezero == '1' * ol
assert eone == oc + ('Y' * (ol - 1))
assert dzero == inzero
assert done == inone
except AssertionError:
raise AssertionError('Input of length %s failed test' % (i,))
try:
for c in range(1024):
decode('111' + chr(c))
except ValueError:
pass
else:
raise AssertionError('Invalid decode input (%02x) did not throw a ValueError' % (c,))
if __name__ == '__main__':
test()
print("Tests passed")
c32d.py import c32
import hashlib
import struct
def _checksum(v):
return hashlib.sha256(hashlib.sha256(v).digest()).digest()[-4:]
'''
String format:
- c32(Raw format) in reverse order
Raw format:
- 4 bytes checksum
- N bytes data (NOTE: encoded to prevent hidden changes)
- - for script:
- - - N bytes: varint preimage data length
- - - N bytes: preimage data
- - - N bytes: script data
- - for BIP32 HD parent key:
- - - 32 bytes: chain code
- - - 33 bytes: parent pubkey
- - for BIP32 serialized key:
- - - 1 byte: depth
- - - 4 bytes: child number
- - - 32 bytes: chain code
- - - One of:
- - - - 32 bytes: private key data
- - - - 33 bytes: public key data
- 1 byte flag (ignored if unknown)
- 1 byte type
- - 01 script (with preimage data)
- - 02 script hash preimage
- - 03 BIP32 HD parent key
- - 04 BIP32 serialized public key
- 2 bytes namespace (blockchain id)
- - 2d41 Bitcoin ('2bc')
- - 2e01 Namecoin ('2nc')
- - 2e37 Freicoin ('FRC')
'''
class c32d:
__slots__ = ('data', 'ns', 'dtype', 'dflag')
def __init__(self, data, ns, dtype, dflag):
self.data = data
self.ns = ns
self.dtype = dtype
self.dflag = dflag
@classmethod
def decode(cls, s, raw = False):
if not raw:
full = c32.decode(s[::-1])
else:
full = s
csum = bytearray(full[:4])
v = bytearray(full[4:])
# Encode the configuration bytes to simplify decoding
pv = 0xbf
for i in range(len(v) - 1, len(v) - 5, -1):
pv = v[i] ^ (csum[i % 4]) ^ pv
v[i] = pv
v.append(0xbf)
for i in range(len(v) - 1):
v[i] ^= csum[i % 4] ^ v[i + 1]
v.pop()
v = bytes(v)
if csum != _checksum(v):
raise ValueError('c32d checksum wrong')
o = cls(None, None, None, None)
o.data = v[:-4]
o.dflag = v[-4]
o.dtype = v[-3]
o.ns = struct.unpack('!H', v[-2:])[0]
return o
def encode(self, raw = False):
try:
v = self.data + struct.pack('!BBH', self.dflag, self.dtype, self.ns)
except struct.error as e:
raise ValueError(e)
csum = bytearray(_checksum(v))
v = bytearray(v)
pv = 0xbf
for i in range(len(v) - 1, -1, -1):
pv = v[i] ^ csum[i % 4] ^ pv
if i < len(v) - 4:
v[i] = pv
v = csum + bytes(v)
if raw:
return v
return c32.encode(v)[::-1]
decode = c32d.decode
def encode(*a, **ka):
return c32d(*a, **ka).encode()
def test():
c32.test()
for (p, s, raw) in (
((b'', 0, 0, 0), '1111115Fd9acc', b'\xb5\xa5\x0c\xb9\x00\x00\x00\x00'),
((b'test', 4232, 142, 219), '955OGe8hOGc97hH4EJj1', b'?V\x1e\\d/\x1cq\xdb\x8e\x10\x88'),
((b'\xff' * 0x100, 0xffff, 0xff, 0xff), 'YYYYYYc327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGt9n2YYbeH63jda5GnYjCEO3r8E53dGYFbchrG4c327OYcC6F9Or6r14UYCJtc5UGb2cOdG3', b'\xb0\xce,*\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xc7\x88\xb9j\xbf\xf0\xc1\x12\xff\xff\xff\xff'),
):
(kp, pp) = ({}, p)
for i in range(2):
o = c32d(*pp, **kp)
assert o.data == p[0]
assert o.ns == p[1]
assert o.dtype == p[2]
assert o.dflag == p[3]
kp = {
'data': p[0],
'ns': p[1],
'dtype': p[2],
'dflag': p[3],
}
pp = ()
assert o.encode() == s
assert o.encode(raw=True) == raw
def ensureValueError(f):
try:
f()
except ValueError:
pass
else:
raise AssertionError('Invalid decode input did not throw a ValueError')
ensureValueError(lambda: encode(b'', -1, 0, 0))
ensureValueError(lambda: encode(b'', 0x10000, 0, 0))
ensureValueError(lambda: encode(b'', 0, -1, 0))
ensureValueError(lambda: encode(b'', 0, 0x100, 0))
ensureValueError(lambda: encode(b'', 0, 0, -1))
ensureValueError(lambda: encode(b'', 0, 0, 0x100))
# Invalid c32d
ensureValueError(lambda: decode('1111115Fd9adc'))
ensureValueError(lambda: decode('11A1115Fd9acc'))
# Invalid c32
ensureValueError(lambda: decode('111x115Fd9acc'))
ensureValueError(lambda: decode('1111115Fd9acx'))
if __name__ == '__main__':
test()
print("Tests passed") |
|
|
|
With the May 15 changes right around the corner, please help test some of the stable maintenance versions  These are bugfix-only releases, including minimal compatibility updating for the May 15 changes.Please report bugs by replying to this forum thread. bitcoind and Bitcoin-Qt version 0.7.3 release candidate 3 (sigs) are now available for download:bitcoind and Bitcoin-Qt version 0.6.5 release candidate 3 (sigs) are now available for download:bitcoind and Bitcoin-Qt version 0.5.8 release candidate 3 (sigs) are now available for download:bitcoind version 0.4.9 release candidate 3 (sigs) is now available for download:- Please note: The wxBitcoin GUI client is no longer maintained nor supported; CVE-2012-4682 and CVE-2012-4683 are not fixed in 0.4.x since it does not have any anti-DoS system at all. If you want to be secure against this class of DoS attacks (network flooding of invalid data to verify), upgrade to a newer version!
- Linux: tar.gz
- Windows: installer | zip
- Source: tar.gz | git
See git for full changelog Backport end-of-life (EOL) schedule: - 0.4.x - EOL by 2013-11-21 (2 years after 0.5.0 released)
- 0.5.x - EOL by 2013-03-30 (1 year after 0.6.0 released)
- 0.6.0.x - EOL now: 0.6.0.x is no longer supported
- 0.6.x - EOL by 2013-11-21 (over 1 year after 0.7.0 released)
- 0.7.x - EOL by 2014-02-18 (1 year after 0.8.0 released)
- 0.8.x - Long-Term Support (LTS): 2-3 years after 0.9.0 released
These are not guarantees. If you need me to maintain any branch longer, please let me know ASAP. |
|
|
|
next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): |
|
|
|
Announcing BFGMiner 3.10, the modular ASIC/FPGA miner written in C. BFGMiner features dynamic clocking, monitoring, and remote interface capabilities. "St. Barbara's Faithfully Glorified Mining Initiative Naturally Exceeding Rivals", or just basically a freaking good miner. This code is provided entirely free of charge by the programmer, so donations would be greatly appreciated. Please consider donating: 1QATWksNFGeUJCWBrN4g6hGM178Lovm7WhIf you are donating for a specific bugfix/feature request, please post the Issue number and it will be flagged as " funded". If you find a bug or have a suggestion, please check to see if it's already been reported and, if not, report it. Help can also be obtained (or provided) by joining the support mailing list or IRC: chat.freenode.net #eligiusREAD THE README INCLUDED IN THE ARCHIVE BEFORE ASKING QUESTIONS. Also, please note that this thread is for discussion of BFGMiner, its features and bugs - if you feel the need to troll or talk off-topic, start another forum thread (and PM me with it if you want my attention). If you want to help develop BFGMiner, the best way to get in touch with me is on IRC. We also have a development mailing list, mainly used to pre-announce upcoming releases for third-party packagers. If you would like to be notified of new versions, please join the announcement mailing list. For miners using ModMiner, X6500, or ZTEX devices, you will need to download bitstreams for BFGMiner 3+ to work with your device. Download links and instructions are included in the README.FPGA file. Latest release: 3.10.0 ( announcement & changes) Stable release: 3.5.7Archive of all official release source & binariesFeatures:- A variety of device drivers for Bitcoin (SHA256d):
- Support for getblocktemplate decentralized mining protocol (no proxy needed!)
- Builtin stratum and getwork proxy server
- Scrypt support for both CPU and OpenCL (GPU) please note that this is for research; I do not personally support Litecoin
- Very low overhead free C code for Linux and Windows with very low CPU usage
- Long poll support - will use longpoll from any pool if primary pool does not support it
- epoll support for interrupting FPGA waiting when new work is available without timeout-looping
- Self detection of new blocks with a mini-database for slow/failing longpoll scenarios, maximum work efficiency and minimum rejects
- Heavily threaded code hands out work retrieval and work submission to separate threads to not hinder devices working
- Caching of submissions during transient network outages
- Preemptive fetching of work prior to completion of current work
- Local generation of more valid work (rollntime) whenever possible, as supported on a per-work item basis
- Prevention of stale work submission on new block (submitold also supported)
- Automatically detects failing pools and disables them
- Multi-device support (all or discrete selection)
- Summarised and discrete device data statistics of requests, accepts, rejects, hw errors, efficiency and utility
- Watchdog thread to restart idle threads but not crash machine if they don't respond
- Summary displayed when quitting
- Supports multiple pools with multiple intelligent failover mechanisms
- On the fly menu based management of most settings
- Trickling of extra work to backup pools if primary pool is responding but slow
- On the fly enabling/disable/restarting of devices
- Device temperature monitoring (for devices that support it)
- Reuses persistent connections when possible
- RPC +/- JSON interface for remote control
- Ability to cope with slow routers
- X-Reject-Reason support
- Lots of other stuff I can't remember. See options.
Sample output: bfgminer version 3.10.0 - Started: [2013-08-20 02:03:56] - [ 0 days 00:35:05]
[M]anage devices [P]ool management [S]ettings [D]isplay options [H]elp [Q]uit
Connected to mining.eligi.us diff 32 with stratum as user 1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
Block: ...a83dc890 #249720 Diff:31.3M (223.8Th/s) Started: [01:22:11]
ST:10 F:0 NB:5 AS:0 BW:[341/153 B/s] E:89.27 I: 6.58mBTC/hr BS:89.7k
7/36 77.0°C │ 90.13/91.42/92.50Gh/s │ A:2171 R:7+0(.49%) HW:430/.62%
───────────────┼───────────────────────┼────────────────────────────────────────
BFL 0: 65.9°C │ 877.7/871.2/940.5Mh/s │ A: 20 R:0+0(none) HW: 0/none
BFL 1: 68.0°C │ 30.58/29.63/30.37Gh/s │ A: 733 R:3+0(.64%) HW: 8/.05%
BFL 2: 78.0°C │ 56.98/58.81/59.58Gh/s │ A:1379 R:4+0(.44%) HW:195/.68%
MMQ 0: 50.0°C │ 799.8/785.1/537.3Mh/s │ A: 15 R:0+0(none) HW: 21/5.7%
XBS 0: 48.2°C │ 398.0/400.3/ 8.18Mh/s │ A: 4 R:0+0(none) HW: 51/ 25%
ZTX 0: │ 198.5/197.6/196.7Mh/s │ A: 3 R:0+0(none) HW: 27/none
ZTX 1: │ 849.0/836.6/992.4Mh/s │ A: 20 R:0+0(none) HW:129/.70%
───────────────┴───────────────────────┴────────────────────────────────────────
[2013-08-02 02:38:58.462496] Accepted 0321a601 BFL 2p pool 0 Diff 81/32
[2013-08-02 02:38:59.007820] Accepted 00c348b2 BFL 2d pool 0 Diff 335/32
[2013-08-02 02:38:59.133534] Accepted 05b3443a BFL 2n pool 0 Diff 44/32
[2013-08-02 02:38:59.785127] Accepted 07563198 ZTX 1a pool 0 Diff 34/32 --- Pool menu: 0: Enabled Strtm Priority 0: stratum+tcp://stratum.mining.eligius.st:3334 User:1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
1: Disabled GWork Priority 1: http://127.0.0.1:9332 User:x
Current pool management strategy: Load Balance
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue
Device management menu: Select processor to manage using up/down arrow keys
MMQ 0d: 41.0°C │ 194.0/190.9/32.98Mh/s │ A: 4 R:0+0(none) HW: 0/none
ModMiner LJRalpha from BTCFPGA
Serial: 19191F145358077D4FAADA7AF5000004
Clock speed: 194
[D]isable [C]lock speed
Or press Enter when done Select processor to manage using up/down arrow keys
OCL 0 : 77.0C | 272.2/272.2/265.7Mh/s | A:2992 R:13+0(.43%) HW:0/none
I:10 F: 69% (2655 RPM) E: 765 MHz M: 1000 MHz V: 1.088V A: 99% P: 0%
Last initialised: [2013-07-08 05:33:26]
Thread 0: 90.9 Mh/s Enabled ALIVE
Thread 1: 90.6 Mh/s Enabled ALIVE
Thread 2: 90.8 Mh/s Enabled ALIVE
[D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press Enter when done Change GPU settings menu: Temp: 72.0 C
Fan Speed: 50% (4489 RPM)
Engine Clock: 950 MHz
Memory Clock: 825 Mhz
Vddc: 1.175 V
Activity: 99%
Powertune: 20%
Fan autotune is enabled (0-85)
GPU engine clock autotune is enabled (880-950)
Change [A]utomatic [E]ngine [F]an [M]emory [V]oltage [P]owertune
Or press any other key to continue
Settings menu: [L]ongpoll: On
[Q]ueue: 0
[S]cantime: 60
[E]xpiry: 120
[R]etries: -1
[W]rite config file
[B]FGMiner restart
Select an option or any other key to return
Display menu: [N]ormal [C]lear [S]ilent mode (disable all output)
[D]ebug:off
[P]er-device:off
[Q]uiet:off
[V]erbose:off
[R]PC debug:off
[W]orkTime details:off
su[M]mary detail level:devices
[L]og interval:5
[Z]ero statistics
Select an option or any other key to return On exiting: Summary of runtime statistics:
Started at [2011-07-19 14:40:09]
Runtime: 2 hrs : 31 mins : 18 secs
Average hashrate: 1680.1 Megahash/s
Solved blocks: 0
Best share difficulty: 49
Share submissions: 3489
Accepted shares: 3489
Rejected shares: 0 + 9 stale (0.00%)
Accepted difficulty shares: 32
Rejected difficulty shares: 0
Hardware errors: 3
Efficiency (accepted shares * difficulty / 2 KB): 0.05
Utility (accepted shares / min): 34.26/min
Unable to get work from server occasions: 16
Work items generated locally: 330
Submitting work remotely delay occasions: 33
New blocks detected on network: 10
Pool: http://getwork.mining.eligius.st:8337
Share submissions: 3426
Accepted shares: 3426
Rejected shares: 0 + 0 stale (0.00%)
Accepted difficulty shares: 31
Rejected difficulty shares: 0
Efficiency (accepted * difficulty / 2 KB): 0.08
Unable to get work from server occasions: 0
Submitting work remotely delay occasions: 0
Summary of per device statistics:
ICA 0: | 375.9/376.0/349.5Mh/s | A: 487 R:4+0(none) HW: 0/none
MMQ 0: 46.0C | 629.9/632.0/526.8Mh/s | A: 734 R:0+0(none) HW:196/none
XBS 0: 46.9C | 392.0/397.8/398.3Mh/s | A: 555 R:0+0(none) HW: 57/none
ZTX 0: | 198.6/198.5/190.2Mh/s | A: 265 R:0+0(none) HW: 95/none
ZTX 1: | 855.0/848.7/825.3Mh/s | A:1150 R:4+0(none) HW:176/none
|
|
|
|
As of yesterday, I have my first ASIC:   |
|
|
|
Now that 0.8.0 is tested and out the door, please help test some of the stable maintenance versions These are bugfix-only releases. 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. Also note that CVE-2012-4682 and CVE-2012-4683 are not fixed in 0.4.x: 0.4.x did not have any anti-DoS system at all, and that is not changed with this release. If you want to be secure against this class of DoS attacks (network flooding of invalid data to verify), upgrade to a newer version! As there will now be 6 stable branches, I am announcing the following end-of-life (EOL) schedule. - 0.4.x - EOL by 2013-11-21 (2 years after 0.5.0 released)
- 0.5.x - EOL by 2013-03-30 (1 year after 0.6.0 released)
- 0.6.0.x - EOL now: this is the last release of 0.6.0.x
- 0.6.x - EOL by 2013-11-21 (over 1 year after 0.7.0 released)
- 0.7.x - EOL by 2014-02-18 (1 year after 0.8.0 released)
- 0.8.x - Long-Term Support (LTS): 2-3 years after 0.9.0 released
These are not guarantees. If you need me to maintain any branch longer, please let me know ASAP. bitcoind and Bitcoin-Qt version 0.7.3 release candidate 1 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.5 release candidate 1 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.11 release candidate 1 is now available for download at: bitcoind and Bitcoin-Qt version 0.5.8 release candidate 1 ( sigs) are now available for download at: bitcoind version 0.4.9 release candidate 1 ( sigs) is now available for download at: Important fix: These releases should not be vulnerable to Sergio's "know your peer public addresses in 14 minutes" vulnerability. See git for full changelog |
|
|
|
BFGMiner (St. Barbara's FPGA/ GPU Miner) 3.0 will be featuring and refocussing on ASICs. Therefore, the original name no longer really fits anymore. Since I can't think of any obvious fit, I've decided to have a little contest to see if anyone can come up with a new name for it. Bonus points if you can make it elegantly fit the current "BFGMiner" abbreviation-name by simply redefining "F" and "G". If I use your suggestion, there will be a Bitcoin reward. The exact amount will be based on how good I think it works, but probably 200 - 600 TBC (about 0.33 - 1 BTC). NOTE: This contest has completed. Thanks for participating. |
|
|
|
In A.D. 2013
War was Beginning. wizkid057: What happen ? Inaba/Josh: Somebody set up us the bomb. PiUK: We get signal. wizkid057: What ! PiUK: Main stats turn on. (screen turns on displaying a shadowy masked figure)wizkid057: It's you !! Mystery ASIC Miner: How are you gentlemen !! Mystery ASIC Miner: All your blocks are belong to us. wizkid057: What you say !! Mystery ASIC Miner: You have no chance to mine make your time. Mystery ASIC Miner: Ha ha ha ha ... wizkid057: Inaba !! Inaba/Josh: Turn on every 'RIG'!! Inaba/Josh: You know what you doing. Inaba/Josh: Mine 'RIG'. Inaba/Josh: For great justice. Cast: Disclaimer: This is an entirely fictional record. If you don't get it, click here. |
|
|
|
|
I took a few hours to do some mining protocol bandwidth usage comparison/tests on my 2.5 Gh/s development mining rig. For each protocol, I gave it 10 minutes and measured its bandwidth usage in terms of (difficulty-1) shares per 2 KB (in both directions). I chose 2 KB because this is roughly the amount of bandwidth used to mine 1 share using the original no-rollntime getwork protocol, and therefore this metric gives approximately 1.00 "bandwidth-based efficiency" per the classic 100% "work-based efficiency" (what BFGMiner displays now).
Stratum ( blind ): 7.44
getwork (rolling): 2.19
getwork (no roll): 1.08
getblocktemplate : 0.33
Stratum (secured): 0.17
Stratum is updating every 55 seconds; GBT every 80 seconds. If secured stratum updated only every 80 seconds, its efficiency would be 0.25. Most likely the difference between this 0.25 and GBT's 0.33 is accounted for by the gzip compression employed by GBT.
Note that these numbers do not take into account scalability. The main benefit (in terms of bandwidth usage) for both GBT and stratum is that they scale without using more bandwidth. I will probably do another run of bandwidth testing when ASICs ship.
They also don't account for Bitcoin security: getwork and blind stratum, though far more bandwidth-efficient at 2.5 Gh/s, give the pool the ability to do double-spends and other kinds of attacks on Bitcoin. Even if you decide to trust your pool operator, this makes the pool a huge target for crackers since it enables them to abuse it to attack Bitcoin. With blind mining protocols, all it takes is someone cracking the top 3 biggest pools to 51% the network.
To try to avoid pool differences affecting the results, all the measurements were made on the Eligius mining pool within the same timeframe.
|
|
|
|
next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Due to Coin Control's poor design and abandonment, it has begun to bitrot rapidly. This will probably be the last next-test supporting it, unless someone steps up to maintain it. Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETAlso note that this is based on code that will become 0.8 including the "ultraprune" block storage rewrite. The master code does not support upgrading from older versions yet, but this next-test includes a HACKY upgrader if it detects such a condition. Note that in any case, the block chain of both your old client and this new one will be saved on your disk. That means about 5 GB for the old one and about 5 GB for the new one (unless your OS supports hard links, which the HACK will use if possible). Wallet is currently considered to be forward and backward compatible, but please still back it up!Today's next-test includes the following pull requests (green are merged now; red are disputed): |
|
|
|
We're planning a Bitcoin meetup in Orlando, Florida (near UCF) on November 20th at 6 PM. PM socrates1024 (aka amiller) for directions. Planned attendee list: - Myself
- Gregory Maxwell (Bitcoin developer)
- Forrest V. (p2pool)
- amiller
- (possibly) grubles (BitVPS)
- (maybe) Simran
- (maybe) Aaaron (BAMT)
- (maybe) you?
- ...
|
|
|
|
Many (most?) 7-port USB hubs on the market seem to be made up of two 4-port controller chips internally (with the 4th port on the 1st controller connected to the upstream port on the 2nd). Since USB has a 5-hub chain limit, this adds up fast. I'm looking for a 7-port USB hub that is built on a true 7-port USB controller chip. Unfortunately, I haven't managed to find out which those are. As far as I know, the only controller chips that support true 7 ports downstream are: - SMSC USB2507
- SMSC USB2517
- TI TUSB2077A
- REA uPD720113
I presume such a USB hub will also appear to the computer (lsusb on Linux, at least) as a single USB hub, and dual-4-ports as two USB hubs. Information is welcome (eg, models that are true 7-port hubs), as well as offers to sell such a hub. Bonus for something I can use for charging, and/or working per-port power switching (this lets your computer turn each port on/off). Thanks, Luke |
|
|
|
next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Due to Coin Control's poor design and abandonment, it has begun to bitrot rapidly. This will probably be the last next-test supporting it, unless someone steps up to maintain it. Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): |
|
|
|
Now that 0.7.0 is tested and out the door, please help test some of the stable maintenance versions These are bugfix-only releases. 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. Also note that CVE-2012-4682 and CVE-2012-4683 are not fixed in 0.4.8: 0.4.x did not have any anti-DoS system at all, and that is not changed with this release. If you want to be secure against this class of DoS attacks (network flooding of invalid data to verify), upgrade to a newer version! bitcoind and Bitcoin-Qt version 0.6.4 release candidate 3 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.10 release candidate 3 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.5.7 release candidate 3 ( sigs) are now available for download at: bitcoind version 0.4.8 release candidate 3 ( sigs) is now available for download at: PROTOCOL UPDATES- BIP 34: Block height in coinbase as a new block rule (includes minimal adaptations to getmemorypool in 0.5+)
- Support for sending to script (P2SH) addresses (BIP 13 + BIP 16)
BUG FIXES- Fix DoS vulnerabilities in alert system (CVE-2012-4682 and CVE-2012-4683; (0.5+ only).
- Do not consider inbound peers for outbound network group exclusion.
- Apply BIP 30 checks to all blocks except the two historic violations.
- Special-case the last alert to protect against the alert key ever being compromised.
- Bitcoin-Qt: Ensure changes to preferred Bitcoin unit is immediately reflected in the GUI.
- Bitcoin-Qt: Make sort and filters for transactions and labels case-insensitive.
- Bitcoin-Qt: Override progress bar on platforms with segmented progress bars.
- Bitcoin-Qt: Updated all translations from Transifex.
- Fixed numerous typos and grammatical errors.
- Resized the address book page to fix issue #1062 (0.6.0.10 and 0.6.4).
- bitcoind: Fix building on MingW/OSX with USE_UPNP=- option (0.5+).
- Fix build version generation failure when compiling on Windows (0.6.4).
- Various other minor bug fixes, including test suite fixes and workaround for distcc build problems.
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Sergio Lerner Gavin Andresen Philip Kaufmann fanquake xanatos Wladimir J. van der Laan Gregory Maxwell Matt Corallo Ricardo M. Correia Michael Ford Jeff Garzik Pieter Wuille Rune K. Svendsen Stephane Glondu |
|
|
|
Since Eleuthria and slush have both recently announced their own developed-behind-closed-doors mining protocols, I felt it appropriate to make a thread here for end-user discussion of the "getblocktemplate" standard which they intend to compete with. As a poolserver author, a pool operator, a miner author, and a contributor to the reference client, my life is not improved by having yet another protocol to support, and what's bad for the authors of the infrastructure tools is also bad for all their users. Getblocktemplate Features- Decentralized: the miners decide what they will mine, and make their own blocks - no more blindly giving up mining control to pool operators
- ASIC-ready: miners can produce as much work as they need with a single request
- Usable yesterday: Eligius has supported it since February, and more pools real soon
- Solo mining: just point your miner to bitcoind 0.7 and mine by yourself (no bitcoind load issues)
- Simple: the basic implementation requires only minimal block building
- Extensible: extensions are available today for miners who wish to take more control over their miners, and future improvements can easily be added later
DocumentationSee the new Bitcoin Wiki page for getblocktemplate, with lots of useful resources including end user and developer documentation. Technical specifications: Supported by... (post or PM me to get yours added) Poolservers (providing getblocktemplate to miners): Mining software: Libraries for mining software: Mining pools: History/BackgroundGetblocktemplate's origins trace back to forrestv's getmemorypool JSON-RPC method for bitcoind. He created it so that his pool (P2Pool) could piggy-back on bitcoind so as to avoid harming the Bitcoin network (up to this point, it mined only empty blocks that never confirmed transactions). Having been fighting with scalability problems in pushpool/bitcoind for months on my pool (Eligius), I set out to implement a fast pool server using getmemorypool to do its own block production (this became Eloipool, this first open source makes-its-own-blocks poolserver). Other poolservers also implemented block creation using getmemorypool over the months following. At about the same time, interest in decentralizing pooled mining became a hot topic. While BitPenny had initially released its own decentralized mining proxy months prior, P2Pool's implementation became rapidly popular. Anyone involved in Bitcoin mining protocols could see the need to move control of block creation back into the hands of the miners. Unfortunately, both BitPenny and P2Pool had used very pool-specific proprietary protocols to implement their decentralization. On the other hand, getmemorypool was almost a perfect fit for the task - it just lacked support for the now-ubiquitous pooled mining extensions that had developed around the getwork protocol over time. In February, I implemented and deployed a first draft of getmemorypool mining support in Eloipool (and on Eligius) along with a proof-of-concept getwork proxy (now known as gmp-proxy), adding revisions as needed to function as a general-purpose decentralized mining protocol. After I had confirmed it was working, I documented and proposed it on the Bitcoin development mailing list for review on February 28th, where discussion began on what was missing and what needed to be changed or clarified. During the following few months, a number of others, both developers and testers, provided constructive criticism and suggestions, which were integrated into the standard. I also actively encouraged participation in the development of the standard among pool operators and poolserver authors, especially as it became necessary to move forward into the ASIC "mining generation". Eventually, it was decided it would be best to rename it to the more appropriate "getblocktemplate" name and drop backward compatibility with getmemorypool for simplicity. The standard was split into two pieces and the technical specification can be found in BIP 22 and BIP 23. Support for getblocktemplate mining was announced for BFGMiner a week ago, and is currently functional (implementing the basics is quite easy) though not entirely optimized yet. A number of other software developers and pools have told me they intend to add getblocktemplate support soon. (side note: all of this occurred before Eleuthria or slush made their protocols public, and neither of them chose to participate in the open development of the getblocktemplate standard)ContributeAll that being said, there is always room for improvement. Reception of the proprietary proposals strongly suggests getblocktemplate is in desperate need of good miner-side example documentation. If you have the time to help bring getblocktemplate to everyone sooner in any way, please get in touch Thanks to... (in no particular order) - Forrest Voight
- Pieter Wuille
- Jeff Garzik
- Gregory Maxwell
- Geir Harald Hansen
- Gavin Andresen
- Stefan Thomas
- Michael Grønager
- ...anyone else I forgot to mention
|
|
|
|
 First-class messaging, where the "Signatures" tab is part of the main window, was originally the default mode of operation for the Sign Message GUI function, but was relegated to the menu by default due to uncertainty of how much use it would get. I think 0.6 has proven it useful (for example, Bitcoin OTC now uses it for primary authentication) and it should be given first-class by default. However, others disagree and even want to remove the option (to make it first-class) entirely. Supposedly I'm the only one who wants message signatures to be first-class. I am hoping this poll will prove the opposite. First-class messaging is a compile-time feature for Bitcoin-Qt 0.6. By adding the FIRST_CLASS_MESSAGING=1 option to qmake, builds will treat message signing the same way as other Bitcoin-Qt functions, instead of relegated to another dialog via the menu as it is by default. On Gentoo, users can enable it simply by installing with the "1stclassmsg" USE flag. Note that the Verify Message will be available with both first-class and second-class messaging. |
|
|
|
|
Show Posts
