Bitcoin Forum
August 21, 2017, 10:08:56 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 »
1  Bitcoin / Bitcoin Discussion / PSA: Miners SHOULD NOT signal segwit if the community is not in widespread agre on: November 20, 2016, 02:29:52 AM
Softforks require community support, and miners should evaluate this before signalling activation of them. If the community is significantly divided over whether a softfork should be deployed, miners should not signal support for the softfork until this contention is resolved.

Bitcoin Core and [segwit-capable] derivatives by default will indicate to segwit-enabled miners that they should signal for segwit support, but GBT's versionbits support (see BIP 9) is intentionally designed such that the miner may safely choose to ignore this recommendation and omit the signal - Core does not force anyone to signal segwit. Miners and pools should choose whether to signal for segwit (and other softforks or policy decisions) on their own, and not rely on defaults.

People using stratum mining pools should note that they may not be able to override the pools' decisions. If your pool does not disclose to you whether they signal for a given softfork, or they signal (or don't-signal) for one inappropriately, you should switch to a pool that matches your position.

Note that I am intentionally not saying whether or not segwit actually is controversial here. Personally, I support segwit and think the only rational objection is that the block size limit increase may be unsafe if we cannot trust miners to continue making 1 MB or smaller blocks for the near future. But the community should make their own decision (perhaps post your position here for miners to see), and miners should decide whether or not to signal based on the community's consent.
2  Other / Bitcoin Wiki / Recent changes 5000 change limitation on: August 14, 2015, 04:44:02 AM
Any way to overcome the wiki's 5000 change limit for RecentChanges? I've fallen behind... Sad
3  Bitcoin / Mining software (miners) / BFGMiner 5.4.2: GBT+Stratum, RPC, Mac/Linux/Win64, Antminer S1-S5, solo stratum on: November 29, 2014, 03:22:18 AM
Announcing BFGMiner 5.4, the modular cryptocurrency 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: 1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh

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 #eligius
READ THE README FILES 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 us 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.

Latest release: 5.4.2 (announcement & changes)Stable release: 4.10.6
Archive of all official release source & binaries

Features:
Sample output:
Code:
 bfgminer version 5.4.2 - Started: [2014-06-10 20:13:01] - [  0 days 06:15:32]
 [M]anage devices [P]ool management [S]ettings [D]isplay options  [H]elp [Q]uit
 Pool 0: ...ning.eligius.st  Diff:128  +Strtm  LU:[02:28:32]  User:1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
 Block #305190: ...6e8ba4d9  Diff:11.8G (84.16P)  Started: [02:07:22]  I:1.04mBTC/hr
 ST:156  F:0  NB:31  AS:0  BW:[269/ 12 B/s]  E:1127.28  BS:21.8M
 5/24   63.0C | 94.10/98.68/95.60Gh/s | A:1974 R:2+2(.20%) HW:5729/2.6%
--------------------------------------------------------------------------------
 BFL 0: 54.0C |  8.11/ 8.10/ 7.65Gh/s | A:  62 R:1+2(4.6%) HW: 273/1.3%
 HBR 0: 63.0C | 22.91/22.85/21.55Gh/s | A: 208 R:0+0(none) HW:3022/5.4%
 TBF 0: 28.0C |  5.13/ 5.10/ 4.89Gh/s | A:  49 R:0+0(none) HW: 331/4.5%
 PXY 0:       | 27.85/30.23/29.84Gh/s | A: 358 R:1+0(.28%) HW: 450/1.0%
 RKM 0: 40.0C | 30.10/32.40/31.67Gh/s | A:1297 R:0+0(none) HW:1653/.92%
--------------------------------------------------------------------------------
 [2014-06-11 02:28:10] Accepted 00c819ef HBR 0d Diff 327/255
 [2014-06-10 02:28:13] Accepted 012058dd PXY 0  Diff 227/128
 [2014-06-11 02:28:15] Accepted 01778be1 RKM 0b Diff 174/128
---
Pool menu:
Code:
0: Enabled  Strtm Quota 1 Pool 0: stratum+tcp://stratum.mining.eligius.st:3334  User:1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
1: Disabled GWork Quota 1 Pool 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:
Code:
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
Code:
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:
Code:
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:
Code:
[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:
Code:
[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:20
S[T]atistical counts: absolute
[Z]ero statistics
Select an option or any other key to return


On exiting:
Code:
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

GUI frontends:
Bare-metal operating systems with BFGMiner:
4  Bitcoin / Hardware / Windows miners beware: FTDI driver update may brick hardware! on: November 04, 2014, 10:09:03 AM
Ars Technica has an article about Windows Update pulling in a driver update for the popular FTDI chipset bricking knock-off chips.
I don't know if any mining hardware is using these knock-off chips, but I would suggest being careful about connecting anything to a Windows system for now.
Note that if you have the WinUSB driver installed (BFx2 and cgminer users), you shouldn't be affected - but if it were me, I wouldn't risk it.

If you know devices affected, please post here to let others know.
5  Economy / Computer hardware / WTB SHA2 mining hardware at break-even prices on: September 02, 2014, 08:00:27 PM
If anyone wants to get rid of their miners, I'm willing to pay a reasonable price for them.
Note that I don't care what the market prices are, only what they're likely to break even with.
As a rule, go to https://tradeblock.com/mining/ and enter hash rate, power use (at the wall), your asking price, shipping price, and a reasonable misc costs estimate (ie, PSU if you're not including that). Set initial mining date no earlier than when it would be delivered to me.
Leave everything else (including 2% "pool fee", network stats, and conversion rate) at the defaults.

If it shows a break-even in the next year, I'm interested - please PM me your tradeblock analysis link (see "Share your analysis").

This applies only for SHA2 hardware that is already supported by BFGMiner, possibly including hardware on the "planned" list.
Non-SHA2 hardware and/or unsupported-by-BFGMiner hardware, I am willing to consider at significantly-better-than-breakeven prices (but note I will not sell scamcoins, which effectively means non-SHA2 is donate-only).

No guarantees on purchase until I get a sense for interest (or lack thereof).
6  Bitcoin / Hardware / Mining manufacturer tech guidelines on: August 22, 2014, 01:18:06 PM
I've started a wiki page with advice for mining manufacturers when producing new mining hardware.
It's just a first draft at this point, but addresses many of the more common mistakes hardware has been released with in the past, as well as suggests ways all current hardware could be improved on.

Contributions are welcome, of course. If you do not already have a wiki account, feel free to post your suggestions on this thread, or request your wiki account be given edit privileges on the wiki subforum.
7  Bitcoin / Mining software (miners) / OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: May 26, 2014, 10:16:44 PM



Announcing BFGMiner 4.10, the modular cryptocurrency 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: 1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh

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 #eligius
READ THE README FILES 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 us 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.

Latest release: 4.10.0 (announcement & changes)Testing release: 4.7.2Stable release: 3.10.7
Archive of all official release source & binaries

Features:
Sample output:
Code:
bfgminer version 4.10.0 - Started: [2014-06-10 20:13:01] - [  0 days 06:15:32]
 [M]anage devices [P]ool management [S]ettings [D]isplay options  [H]elp [Q]uit
 Pool 0: ...ning.eligius.st  Diff:128  +Strtm  LU:[02:28:32]  User:1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
 Block: ...6e8ba4d9 #305190  Diff:11.8G (84.16P)  Started: [02:07:22]
 ST:156  F:0  NB:31  AS:0  BW:[269/ 12 B/s]  E:1127.28  I:1.04mBTC/hr  BS:21.8M
 5/24   63.0C | 94.10/98.68/95.60Gh/s | A:1974 R:2+2(.20%) HW:5729/2.6%
--------------------------------------------------------------------------------
 BFL 0: 54.0C |  8.11/ 8.10/ 7.65Gh/s | A:  62 R:1+2(4.6%) HW: 273/1.3%
 HBR 0: 63.0C | 22.91/22.85/21.55Gh/s | A: 208 R:0+0(none) HW:3022/5.4%
 TBF 0: 28.0C |  5.13/ 5.10/ 4.89Gh/s | A:  49 R:0+0(none) HW: 331/4.5%
 PXY 0:       | 27.85/30.23/29.84Gh/s | A: 358 R:1+0(.28%) HW: 450/1.0%
 RKM 0: 40.0C | 30.10/32.40/31.67Gh/s | A:1297 R:0+0(none) HW:1653/.92%
--------------------------------------------------------------------------------
 [2014-06-11 02:28:10] Accepted 00c819ef HBR 0d Diff 327/255
 [2014-06-10 02:28:13] Accepted 012058dd PXY 0  Diff 227/128
 [2014-06-11 02:28:15] Accepted 01778be1 RKM 0b Diff 174/128
---
Pool menu:
Code:
0: Enabled  Strtm Quota 1 Pool 0: stratum+tcp://stratum.mining.eligius.st:3334  User:1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
1: Disabled GWork Quota 1 Pool 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:
Code:
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
Code:
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:
Code:
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:
Code:
[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:
Code:
[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:20
S[T]atistical counts: absolute
[Z]ero statistics
Select an option or any other key to return


On exiting:
Code:
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

GUI frontends:
Bare-metal operating systems with BFGMiner:
8  Other / Bitcoin Wiki / Vandal cleanup task force? on: May 13, 2014, 10:56:36 PM
Any volunteers to clean up after vandals?

Particularly this one did a lot of spamming.

Need someone(s) to sort through which of it is actual spam, which is legit, etc; and revert it as needed.

Thanks
9  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.8.7 backport, release candidate 1 on: March 25, 2014, 07:28:17 AM
Bitcoin Core version 0.8.7 release candidate 1 (sigs) is now available for download:
This is a maintenance release to fix bugs only.
Users should upgrade to 0.9.0 if possible, and only use 0.8.7 if they encounter trouble with that.
Due to lack of testing, backport stable versions are unlikely to ever reach a final release.

Please report bugs by replying to this forum thread.

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version older than 0.8, the first time you run 0.8.7, your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine.

Transaction malleability-related fixes

This release contains a few fixes for transaction ID (TXID) malleability issues:

  • -nospendzeroconfchange command-line option, to avoid spending zero-confirmation change
  • IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions
  • Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs.
  • Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.

0.8.7 Release notes


Wallet:

  • Bug fixes to correctly compute the balance of wallets containing double-spent (or mutated) transactions
  • Don't create empty transactions when reading a corrupted wallet
  • Only create signatures with low S values

GUI:

  • Fix richtext detection hang issue on very old Qt versions

RPC:

  • New notion of 'conflicted' transactions, reported as confirmations: -1
  • Reject insanely high fees by default in 'sendrawtransaction'
  • Explicitly ensure that wallet is unlocked in `importprivkey`
  • Add check for valid keys in `importprivkey`

Command-line options:

  • New option: -nospendzeroconfchange to never spend unconfirmed change outputs

Block-chain handling and storage:

  • Add a new checkpoint at block 279,000

Protocol and network:

  • Added new DNS seed from bitcoinstats.com

Warning


There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Hence it is recommended to use a 64-bit executable if possible. A 64-bit executable for Windows is available for 0.9.

Credits


Thanks to everyone who contributed to this release:

  • Wladimir J. van der Laan
  • Michagogo
  • Luke Dashjr
  • Philip Kaufmann
  • Pieter Wuille
  • Gregory Maxwell
  • Gavin Andresen
  • Peter Todd
  • Christian Decker
  • Matt Corallo
  • b6393ce9-d324-4fe1-996b-acf82dbc3d53
  • fanquake
  • regergregregerrge
10  Bitcoin / Meetups / North-of-Tampa Bitcoin Meetup Dec 11 or 12 on: November 29, 2013, 11:34:45 PM
Anyone interested?
11  Bitcoin / Mining / Miners: Time to deprioritise/filter address reuse! on: November 15, 2013, 05:12:16 AM
Addresses have always been considered single-time-use since Satoshi released the whitepaper.
While the community has tolerated reuse for things like donation addresses due to lack of convenient alternatives, it looks like the time is here early that this needs to stop.
I had hoped to defer anything in this area until wide deployment of the payment protocol (which should make such things unnecessary), but our hands1 are perhaps2 being forced3 to act sooner4.

I am hereby announcing the first release of a the first patch for miners to filter address reuse:
unique_spk_mempool for bitcoind 0.8.5
For now, since this is still somewhat common, this just deprioritises it to one reuse per block.
If I have time, I plan to write patches to be more and less aggressive that miners can choose between (or maybe others will beat me to it!).

If you want to support this move, encourage your favourite mining pool to adopt this or a similar policy change, or use a decentralised pool that lets you apply it yourself.

In collaboration with wizkid057, the Eligius mining pool (15% of total network hashing) is now the first to deploy this change on an experimental basis.
12  Bitcoin / Hardware / [OT BFL crud from] BPMC Launch BF1 USB miner on: September 23, 2013, 02:56:40 AM
When Luke Jr. asked for a BF1 I gave him the same speech. No I wouldn't ever think about putting a device in your hand due to your lack of integrity with the whole BFL fiasco. Open Source Software developers and Open Source projects in general need to remain neutral but these guys are not playing that way. CKolivas is neutral and we need more people like that.
I wasn't going to say anything in public, but since you see fit to bring it up...
While I respect your decision not to provide me with a device, I think you have some grossly inaccurate views of at least myself.
It's true that I have been working with Butterfly Labs the longest, but that is a given considering they were the first to market with FPGAs.
I think there are many people who can acknowledge that I have gone an extra mile in remaining vendor-neutral.
13  Bitcoin / Hardware / Hacking BitForce SC firmware with only free software on: July 25, 2013, 09:39:20 PM
Ok, starting a thread here to deal with hacking on BitForce SC firmware using only free software.
Non-free software is off-topic here. Note that closed-source software is always non-free, even if you don't have to pay for it.

Needless to say, if you damage your mining devices doing this, you're on your own.
Neither I nor BFL are likely to provide compensation or any warranty for hacking firmware.

Overview:
1. Toolchain (success, docs WIP)
2. Building (WIP)
3. Flashing (complete)
4. Debugging (nothing done)


Step 1: Toolchain

This is a pain. I'll document it later.
For now, you can play with my (Gentoo-oriented) notes:
Code:
crossdev -t avr32 -s1  # this will fail! but sets up stuff for us


# BEGIN binutils

mkdir -p /etc/portage/patches/cross-avr32/binutils/
cd /etc/portage/patches/cross-avr32/binutils/
PATCHES="
20-binutils.2.20.1-avr32-autoconf.patch
30-binutils-2.20.1-avr32-bfd.patch
31-binutils-2.20.1-avr32-binutils.patch
32-binutils-2.20.1-avr32-gas.patch
33-binutils-2.20.1-avr32-include.patch
34-binutils-2.20.1-avr32-ld.patch
35-binutils-2.20.1-avr32-opcodes.patch
40-binutils-2.20.1-avr32-fixes.patch
41-binutils-2.20.1-avr32-fpu.patch
42-binutils-2.20.1-avr32-bug-7435.patch
50-binutils-2.20.1-avr32-mxt768e.patch
51-binutils-2.20.1-avr32-uc3c.patch
52-binutils-2.20.1-avr32-uc3l0128.patch
53-binutils-2.20.1-avr32-uc3a4.patch
54-binutils-2.20.1-avr32-uc3d.patch
55-binutils-2.20.1-avr32-uc3l3l4.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/binutils-2.20.1/$patch
done

# Possibly change make.conf to MAKEOPTS=-j1 - not sure if necessary


USE='-* multitarget' emerge =cross-avr32/binutils-2.20.1-r1

# interrupt build (Ctrl-Z) immediately after patches are applied
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/binutils-2.20.1
$EDITOR opcodes/Makefile.am  # find avr-dis.c and add under it: avr32-asm.c avr32-dis.c avr32-opc.c
for d in . gold intl libiberty gprof ld binutils etc gas opcodes bfd; do ( cd "$d"; autoreconf; ); done
fg

aclocal -I config
autoconf
automake
autoheader
for d in bfd opcodes binutils gas ld; do
pushd $d
autoconf
automake
autoheader
popd
done
fg

# interrupt build (Ctrl-Z) after bfd has configured
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/build/bfd
make headers
fg

# DONE binutils


# BEGIN gcc

mkdir -p /etc/portage/patches/cross-avr32/gcc/
cd /etc/portage/patches/cross-avr32/gcc/
PATCHES="
30-gcc-4.4.3-avr32.patch
31-gcc-4.4.3-avr32-rmw.patch
32-gcc-4.4.3-avr32-sleep-builtin.patch
33-gcc-4.4.3-avr32-ucr3fp.patch
34-gcc-4.4.3-avr32-fpu.patch
35-gcc-4.4.3.avr32-delay-cycles.patch
36-gcc-4.4.3.avr32-list-devices.patch
40-gcc-4.4.3-avr32-fpemul-fixes.patch
41-gcc-4.4.3-avr32-fix-const_int_addr.patch
42-gcc-4.4.3-avr32-fix-reorg_opt_bug11763.patch
43-gcc-4.4.3-avr32-4_4_3-upgrade.patch
44-gcc-4.4.3-avr32-bug-12671.patch
45-gcc-4.4.3-avr32-bug-7435.patch
46-gcc-4.4.3-avr32-bug-9675.patch
50-gcc-4.4.3-avr32-mxt768e.patch
51-gcc-4.4.3-avr32-uc3c.patch
52-gcc-4.4.3-avr32-uc3l0128.patch
53-gcc-4.4.3-avr32-uc3a4.patch
54-gcc-4.4.3-avr32-uc3d.patch
55-gcc-4.4.3-avr32-uc3l3l4u.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/gcc-4.4.3/$patch
done

USE='-*' ACCEPT_KEYWORDS=** emerge =cross-avr32/gcc-4.4.3-r3

# DONE gcc


# BEGIN atmel-headers

layman -a luke-jr
ACCEPT_KEYWORDS=** emerge cross-avr32/atmel-headers

# DONE atmel-headers


# BEGIN newlib

mkdir -p /etc/portage/patches/cross-avr32/newlib/
cd /etc/portage/patches/cross-avr32/newlib/
# skip 10-newlib-1.16.0-avr32-atmel-version.patch
PATCHES="
30-newlib-1.16.0-avr32.patch
31-newlib-1.16.0-flashvault.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/newlib-1.16.0/$patch
done

ln -s /usr/portage/sys-libs/newlib /usr/portage/local/crossdev/cross-avr32/
USE=-* ACCEPT_KEYWORDS=** emerge =cross-avr32/newlib-2.0.0

# interrupt build (Ctrl-Z) immediately after source unpacks
cd /var/tmp/portage/cross-avr32/newlib-2.0.0/work/newlib-2.0.0/
for patch in $PATCHES; do
patch -p0 <"/etc/portage/patches/cross-avr32/newlib/$patch"
done
cd newlib
autoreconf
fg

# interrupt build (Ctrl-Z) immediately after you see:
#    >>> Install newlib-2.0.0 into /var/tmp/portage/cross-avr32/newlib-2.0.0/image/ category cross-avr32
mkdir -p /var/tmp/portage/cross-avr32/newlib-2.0.0/image//usr/avr32/lib

# DONE newlib


ln -s /usr/lib/binutils/avr32/2.20.1/ldscripts/ /usr/avr32/lib/


Step 2: Building

TODO. I haven't done this 100% yet.
My BitForce_SC repository has a "make" branch that compiles to a .elf binary for now.


Step 3: Flashing

I decided to use the "TUMPA" JTAG interface (WARNING: this shop closed almost right after I ordered, until Aug 17).
There are many other options (including some nice open hardware you have to build yourself), but I don't have any experience with them (note that it must work at 3.3V!).
NOTE: I think Atmel's "Dragon" adapter will not work for this!

This board has a 20-pin JTAG connector, and the BFL boards have a 10-pin JTAG connector, each with different pinouts (ie, you can't just match half the 20-pin with the 5-pin!)
You want to connect these pins:
Name20-pin/TUMPA10-pin/BFL
VCC/VREF/VTAR14
nTRST38
TDI59
TMS75
TCK91
TDO133
GND20*10*
You can use any GND pin on both ends, only one needs to be connected.

Next, you'll need to install a special version of UrJTAG.
For some reason, they ignored AVR32 flash patches in 2009.
We need that. We also need a part definition for the AVR32 chip in BFL's devices.
I've put all this together in a git clone of UrJTAG for simplicity.
Build this from source and install it.

If you have an Intel HEX firmware (such as the 1.2.5 release binary - which is, by the way, probably compiled only for one particular model), you can convert it to the format needed for UrJTAG using this command:
Code:
srec_cat BitForce_SC-1.2.5.hex  -intel -offset -0x80000000 -byte-swap 4 -o BitForce_SC-1.2.5.bin -binary
Note that UrJTAG for some reason needs the firmware with all the words flipped backward (hence the -byte-swap 4 option).
This may be a bug in the aforementioned AVR32 flash patches, and if so, I may fix it at some point.

Now plug in the TUMPA (or equivalent) and start UrJTAG.
The first thing you need to do is configure your JTAG cable.
For TUMPA, this is:
Code:
cable ft2232 vid=0x0403 pid=0x8A98
Next, configure it for the AVR32:
Code:
detect
initbus avr32 HSBU

Before you flash, you must halt the CPU:
Code:
instruction HALT
shift ir
dr 1
shift dr
shift dr
If the chip is locked (BFL seems to ship at least some this way), you must unlock it (this erases the firmware on it too):
Code:
instruction CHIP_ERASE
shift ir
Now, flash the binary:
Code:
flashmem 0 BitForce_SC-1.2.5.bin
Once this completes, you can reenable the CPU:
Code:
instruction HALT
shift ir
dr 0
shift dr
shift dr


Step 4: Debugging

OpenOCD doesn't seem to have usable AVR32 support yet.
I probably won't give this any attention myself, but feel free to contribute.


See also:
14  Bitcoin / Bitcoin Discussion / Bitcoin-Qt next-test 2013-07-21 on: July 22, 2013, 09:26:14 PM

next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible.
These pull requests are often not well-tested, and may contain serious bugs.

Please note these might possibly corrupt your wallet, destroy your coins (on the network), or worse. No warranty of any kind of provided. BACKUP YOUR WALLET


Today's next-test includes the following pull requests (green are merged now; red are disputed):
15  Bitcoin / Hardware / Block Erupter USB *branding* on: July 05, 2013, 04:02:16 AM
Block Erupters currently come from Bitfountain with the default USB strings of the CP210x UART chip they used:
Code:
 iManufacturer           1 Silicon Labs
  iProduct                2 CP2102 USB to UART Bridge Controller
  iSerial                 3 0001

Since this can (and probably is) used by other, non-mining devices, BFGMiner cannot safely probe it for a miner.
Future versions will look for the iProduct string "Block Erupter" to autodetect, and track statistics better with unique serials.
(If you don't brand your device, it will still work just like it does now!)
Even if you don't use BFGMiner, you might be interested in branding it just for fun, or to distribute to customers if you are a vendor.

With a handy program for programming this chip, these can be branded.

Since this program does not support changing the iManufacturer, I had to go to some extra effort for that.
Here are two EEPROM "hex" files: Bitfountain and BTCGuild

You can use them like so:
Code:
./cp210x-program -w -F eeprom-content.Bitfountain.hex --set-product-string='Block Erupter Sapphire (Red)' --set-serial-number=ljr0001
Then you get:
Code:
 iManufacturer           1 Bitfountain
  iProduct                2 Block Erupter Sapphire (Red)
  iSerial                 3 ljr0001

Editing the hex files for other vendors shouldn't be very hard, but if any vendors would like me to assist in that, send me a PM.

Note: I had to apply a small patch to get cp210x-program to work for me:
Code:
diff -r d852ade43170 cp210x/usb.py
--- a/cp210x/usb.py Fri Sep 10 17:14:59 2010 +0200
+++ b/cp210x/usb.py Fri Jul 05 03:45:45 2013 +0000
@@ -17,7 +17,7 @@
         dll=cdll.LoadLibrary("libusb.dylib")
     elif sys.platform == 'linux2':
         PATH_MAX = 4096
-        dll=cdll.LoadLibrary("libusb.so")
+        dll=cdll.LoadLibrary("libusb-0.1.so.4")
     else:
         raise NotImplementedError("Platform %s not supported by usb.py" % sys.platform)
 except OSError:
16  Bitcoin / Hardware / Free BFL $25-off-chips coupons on: June 16, 2013, 03:35:37 AM
I've decided I'll probably give away my $25-off-chips coupons from BFL, to hardware designers making new products based on them.
Tentative conditions:
  • You must be making a new device; simply building clones of existing BFL devices doesn't count!
  • You must provide specifications and at least one sample unit to me for maintaining BFGMiner support for it.
Quantity of coupon codes per project depends on how many people are interested in taking me up on this, but I should have plenty.
I reserve the right to favour more interesting projects Smiley

So, anyone interested?
17  Bitcoin / Hardware / BFL BitForce SC Firmware source code on: June 15, 2013, 11:07:59 PM
BFL has entrusted me with releasing the source code for their BitForce SC firmware.

Latest version, 1.2.9:
Note, I have not made any changes or even read the code for this yet.
18  Alternate cryptocurrencies / Altcoin Discussion / First (and best) altcoin ever: Tonal Bitcoin (TBC) on: May 28, 2013, 02:53:18 PM
So it occurred to me that TBC doesn't have a forum thread here yet...

I created this altcoin in January 2011 immediately after discovering Bitcoin.
While many altcoins have been created since, none come close to TBC's ideal design:
  • Shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.
  • Mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.
  • Completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.

The main, and only unique, feature of TBC is being based on the innovative Tonal number system.
What Bitcoin aims to do for currency, Tonal aims to do for numbers in general.

Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...

That is, it is a radix 8 × 2 system, similar to hexadecimal.
Because humans naturally perform binary operations (try cutting your next pizza into 5 or 10 slices!), once you get past the learning curve, this power-of-two radix is easier and more powerful to work with.
Why not just use hexadecimal?
  • Ambiguity: "I have a fish!" - is that 1 or 8 × 2?
  • Tonal is actually older! Hexadecimal was invented in 1954, while Tonal goes back to 1862.
  • Hexadecimal is only used or specified for integers, whereas Tonal already defines all sorts of everyday units including lengths, time, capacity, weight, power, gold/silver coinage, calendar, temperature, and even postage stamps and music!
  • Tonal also has defined pronunciations for large numbers, while hexadecimal must be read digit-by-digit.

1 TBC is defined as 1,0000 (tonal) satoshis - that is, 0.00065536 BTC.
This amount was chosen for a number of reasons, including being nicely at four-tonal-places precision (standard for tonal) and balanced with the total number of Bitcoins if it were to achieve worldwide adoption (that is, there would be enough TBCs that everyone could reasonably have some).

Other handy units and their equivalents:
AbbreviationPronunciationTBCBTC
tam-bitcoin
1 0000 0000     
2 814 749.767 106 56
ᵇTBCbong-bitcoin
1 0000     
42.949 672 96
ᵐTBCmill-bitcoin
1000     
2.684 354 56
ˢTBCsan-bitcoin
100     
0.167 772 16
ᵗTBCton-bitcoin
10     
0.010 485 76
TBCbitcoin
1     
0.000 655 36
TBCᵗbitcoin-ton
0.1   
0.000 040 96
TBCˢbitcoin-san
0.01  
0.000 002 56
TBCᵐbitcoin-mill
0.001 
0.000 000 16
TBCᵇbitcoin-bong
0.0001
0.000 000 01
19  Bitcoin / Hardware / Unresponsive Icarus? on: May 22, 2013, 07:19:41 AM
It seems my Icarus has developed a problem while I was at the conference.
The Prolific USB chip responds as usual, and behaves normally; however, sending jobs (including known "test" jobs) never returns any nonces, regardless of how long I wait.
The original cooling (heatsink & fan) is intact and working flawlessly, and I have never connected the JTAG or modified the FPGA or flash contents.
Wondering if anyone else has seen this kind of behaviour, before I start poking around more...
20  Bitcoin / Development & Technical Discussion / [RFC] c32d encoding on: May 15, 2013, 06:32:24 AM
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
Code:
# 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
Code:
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")
Pages: [1] 2 3 4 5 6 7 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!