Bitcoin Forum
November 17, 2018, 06:40:17 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Bitcoin / Development & Technical Discussion / Re: Q:Is there a deterministic private-public keypair generator w/o the BIP32 issue? on: July 30, 2015, 08:17:18 AM

HD Wallets have a flaw that revealing a private key and its parent master public key will reveal its parent master private key. (Described here[1] and here[2]).

Isn't there a similar concept with master public key and master private key that does not suffer from this issue. (Does not have to be ECDSA. I just want a deterministic private-public keypair generator that can publish its master public key).
Depending on what your use case is, this might be useful:
The scheme described by Gus Gutoski will protect a parent private key from the release of a specific number of its child private keys.
2  Bitcoin / Development & Technical Discussion / Re: Numerically finding an optimal block size using decentralisation-utility on: July 05, 2015, 06:06:17 AM

This is not true.  On average every node has to receive each transaction and block only once.  This means that on average each node has to send each transaction once.  Some (fast) nodes may end up sending transactions lots of times.  The closer your node is to miners, the more likely it is to have to send blocks multiple times.

Thank you for helping me find a better value for the bandwidth multiplication factor. My initial guesstimate of 10 was really handwavy and I agree with your methodology. But I do like to use real-world data, so:
  • Number of peers: 20 seems like a good minimum value for a healthy Bitcoin network - 8 for outbound connections, 8 for inbound connections, and a few for crawlers/leechers.
  • tx size: the average tx size of the last 20160 blocks, beginning from block 363900, was 560 bytes.
  • inv messages: My sniffer logged 13743 packets with 18374 inv messages. Including the various protocol overheads, the result was 98 bytes per inv.
  • tx messages: Overhead (as determined from sniffer) was about 90 bytes per tx message - so an average of 650 bytes per tx.
  • block messages: I'll assume overhead is negligible here, since blocks are bulk data. Thus block messages contribute an average of 560 bytes per tx.
The result is (20 * 98 + 2 * 650 + 2 * 560) / (560) = 7.8
I shall update my original post/graphs with this factor.

I'm including overhead because ISPs do count overhead towards caps.

Interesting that nearly half of bandwidth attributable to a single tx is due to inv messages. Looks like there's room for optimisation there.
3  Bitcoin / Development & Technical Discussion / Numerically finding an optimal block size using decentralisation-utility on: July 04, 2015, 09:28:39 AM
Finding an optimal block size is about tradeoffs - too big, and you have centralisation, too small, and Bitcoin cannot support as many users. How can this be quantified? Here is a simple and general figure-of-merit, "decentralisation-utility":

decentralisation-utility = potential number of full nodes * potential number of users

Decentralisation is represented by the potential number of full nodes. Utility is represented by the potential number of users. The question of finding an optimal block size is then: how can decentralisation-utility be maximised? For example, it's better to reduce potential number of users by 20%, if that would mean 30% more potential full nodes.

Potential number of full nodes

For most residential full node operators, the limiting factors will probably be data caps and upload speed. It's difficult to get combined statistics on this, but I did find one excellent data set. The FCC's Measuring Broadband America Report (see contains a wealth of data about broadband Internet connections in the US. Commendably, they have also made the raw data available from The data is supposedly representative of the general consumer population.

The raw data contains cross-referenced upload speeds and total usage (downloaded and uploaded bytes). I will use total usage to represent "proven" capacity - if a user is able to transfer 20 GB/month of any data, this demonstrates that they are capable of transferring 20 GB/month of Bitcoin block data, and that 20 GB/month fits within their data cap. Furthermore, I calculated the maximum amount that could be transferred at their upload speed, and if this was lower than their total usage, then that becomes their proven capacity.

Here are the results:

This graph represents the proportion of users who are capable of transferring the amount on the x-axis. For example, if we set block size limits so that Bitcoin needs 10 GB/month, then 98% of users can run full nodes. But if we set block size limits so that Bitcoin needs 100 GB/month, then only 67% of users can run full nodes.

I'll assume that there are 10,000# people out there wishing to run full nodes. As block size is increased, an increasing proportion of those people will be unable to run full nodes due to lack of data capacity.

Potential number of users

I'll assume that each "user" of Bitcoin requires 1000# bytes of on-chain space each day. This corresponds to 2 - 4 transactions per day, per user. Each MB of block size then supports 144,000 Bitcoin users. Layer-2 networks like Lightning will increase the number of potential users, as users will (on average) require less on-chain space

Combining these

There is still one more question: how does block size (in MB) influence data usage (in MB/month)? I'll assume completely full blocks every 10 minutes, and that block data needs to be transferred a total of 10 times. This is reasonable, as Bitcoin is a P2P gossip network and transactions/blocks may need to be retransmitted to peers. Transferring transactions/blocks a total of 10 times means that a full node can relay to at least 9 peers1 and that results in fast enough propagation (< 5 hops for 10,000 nodes). So for example, 1 MB blocks would require 44.6 GB/month of data capacity (1 MB * 4464 blocks/month * 10). Edit: see, the bandwidth multiplication factor is probably closer to 7.8.

Combining all that, here is what decentralisation-utility looks like:

The optimal block size is about 3.8 MB.

Some issues with this analysis:
  • The dataset is for the US. I was unable to find a good enough dataset for anywhere else.
  • The dataset is from September 2013. Bandwidth capacity and usage has grown since then, and will continue to grow.
  • Proven capacity (i.e. usage) will underestimate actual maximum capacity. This figure of 3 MB is quite conservative.
  • The optimal block size is inversely proportional to the bandwidth multiplication factor. For example, assuming that the factor is 2 instead of 7.8 leads to the conclusion that the optimal block size is 15 MB. A bandwidth multiplication factor of 2 is the theoretical minimum that could be obtained via. improvements to the Bitcoin P2P protocol.

tl;dr: Trading off decentralisation and number of users in the US broadband environment results in an optimal block size of 3.8 MB. With P2P protocol improvements this could be up to 15 MB.

1I'm assuming a future where IBLT is part of the Bitcoin P2P protocol, so that transaction data doesn't need to be sent "twice". I'm also assuming that most non-relaying SPV nodes use bloom filtering, so that not every transaction needs to be relayed to them.
#All parameters marked with "#" are irrelevant to the optimisation. It turns out that tweaking these parameters ends up rescaling the y-axis of the decentralisation-utility graph (which we don't care about), but will leave the x-axis untouched (we do care about that as it has block size in it).
4  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 12, 2015, 12:37:55 PM
Just to make sure everything is clear, the penalty pool is not related to mining pools, despite the usage of the word "pool". I have not talked about mining pools in this discussion.

Sorry my mistake.  I was thinking miners could leave mining pools in this scenario, to benefit from the remaining members of the pool producing larger blocks.
I decided to analyse the situation in the case of mining pools. As a start, I used Meni's parameters as described in

Assume I have 1% of the total hash rate. I am currently in a 90% mining pool. There are also 10 1% miners. Using the results in Meni's post, my expected income per block is 0.04685 BTC.

Will I earn more by leaving the 90% mining pool and solo-mining?

If I solo-mine, the 90% mining pool is now an 89% mining pool and there are 11 1% miners. Solving for these parameters:
n0 = 7217 (slightly smaller)
n1 = 5945 (almost the same)
p = 0.6906 mBTC (slightly larger)
Penalty paid by 1% miners: f(5945) = 0.4602 BTC
Penalty paid by 89% miner: f(7217) = 3.3043 BTC
Average penalty: 0.89*3.3043 + 0.11*0.4602 = 2.9914 BTC
Reward per block for 1% miner: 5945 * 0.0006906 + 2.9914 - 0.4602 = 6.6368 BTC
Reward per block for 89% miner: 7217 * 0.0006906 + 2.9914 - 3.3043 = 4.6712 BTC

My expected income per block is now 0.06637 BTC, 42% higher than when I was in a mining pool. There is a very strong incentive to betray the large mining pool. I have not done any additional calculations, but I suspect it is also profitable for every individual miner in the larger mining pool to leave and solo-mine, or at least join a smaller pool.

Thus a sensible large mining pool operator should not mine supersized blocks. Meni, I realise you've come to this conclusion another way (higher income means higher difficulty), but this is yet another reason why rollover penalties discourage large mining pools from mining large blocks.
5  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 10, 2015, 06:36:30 AM
1. Floating block limits have their own set of problems, and may result in a scenario where there is no effective limit at all.

2. Even if you do place a floating block limit, it doesn't really relieve of the need for an elastic system. Whatever the block limit is, tx demand can approach it and then we have a crash landing scenario. We need a system that gracefully degrades when approaching the limit, whatever it is.
Why not have both an elastic block cap and floating block limits? A common argument against floating block limits is "big miners will create super-sized blocks full of crap to artifically inflate the block limit". This attack is conveniently addressed by your rollover penalties, as the penalty is a function of block size (not of transaction fees), so miners cannot game the system by including self-mined transactions.

Consider the following floating block limit function:
T = k * median(block size of last N blocks)
evaluated every N blocks.
With k = 1.0 and N = something large like 8064, we have an equilibrium situation consisting of the status quo, where everyone stays under the soft cap of T. If a large mining cartel wishes to inflate block sizes against the will of smaller miners, they must begin creating larger blocks and paying penalties towards the smaller miners, for each block. With sufficiently large N, this is not sustainable.

Let's say Bitcoin experiences sustained, long-term growth and the fee pool/demand increases. Now everyone, including smaller miners, is creating blocks larger than T. Everyone pays penalties, but in doing so, the "penalty" isn't really a penalty; everyone receives about as much from the rollover pool as they pay. After 8064 blocks, T increases to account for this genuine, long-term increase in demand.

There are lots of parameters here, and they can be adjusted to disincentivize a mining cartel from artificially inflating block sizes. For example, increasing N and making the limit function f(x) "harder" will both increase the cost to artificially inflate block size limits. Another possibility is setting k < 1.0 (e.g. k = 0.98), which means that maintaining the status quo has a cost. If miners unanimously decide to maintain the status quo, then no-one is actually penalised because everyone receives as much from the penalty pool as they pay. However, if smaller miners feel that the status quo is unreasonable (because of past bloat from a large mining cartel), they can choose to make smaller blocks and "bleed" penalties from the larger miners. However, I am concerned that setting k < 1.0 might implicitly set an absolute minimum transaction fee.

tl;dr version:
With floating block limits + rollover penalties:
mining cartel tries to artificially inflate blocks => they must subsidize smaller miners with penalties
Bitcoin experiences genuine, long-term growth => miners unanimously include more transactions => block sizes will increase
6  Bitcoin / Project Development / Re: [ESHOP launched] Trezor: Bitcoin hardware wallet on: October 03, 2014, 11:01:30 AM
Keys stored in the bootloader are public as asymmetric cryptography is used there. There is no security reason why bootloader should stay closed, but we were quite hesitant to open it because that's the last piece of mosaic that our competition is missing from making a perfect TREZOR clone.
Anyone who wants to clone your code can just upload (unsigned) firmware that dumps the bootloader. The STM32F2xx's level 2 code protection does not prevent flash from being read by code that is running within the microcontroller. No, this won't get you the source, but if you're going to be making a 1:1 copy, you don't need source.
7  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 18, 2013, 04:03:00 PM
For those who are getting "usb_write" errors and are unable to power cycle the boards, here is some firmware: (BTB identifier, for cgminer < 3.6.0) (BBF identifier, for cgminer >= 3.6.0)

This adds a soft watchdog which will auto-reset the microcontroller if the main thread blocks. This doesn't fix the cause of the usb_write errors (I'm still working on that), but it means that if they do occur, your boards won't sit there doing nothing.
8  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 17, 2013, 04:40:17 PM
For those with both Avalon and BitFury-based BitBurners, here is some firmware which will cause the BitBurner Fury boards to be recognised as "BBF" in cgminer >= 3.6.0:
This update does not fix any bugs or improve the hashrate in any way (over any previously released firmware). All it mainly does is change the USB product string so that cgminer uses a different identifier. Also, if you run "./cgminer -n", the Avalon and BitFury BitBurners should be easily distinguishable due to the new product string.

If using this firmware, note that voltage is now set in cgminer using "--bitburner-fury-voltage" instead of "--bitburner-voltage". "--bitburner-fury-voltage" will set the actual voltage, so there's no need for any 300 mV offset. Also, "--bitburner-fury-voltage" only affects boards which identify as "BBF", and "--bitburner-voltage" will only affect boards which identify as "BTB". This makes it more difficult to accidentally swap voltage settings.

The maximum core voltage for the BitBurner Fury boards is 1100 mV. This is a hard limit; if you really want to increase it, you will need to replace R35 (normally 12 k ohm) with something smaller.
9  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 11, 2013, 10:56:53 AM
That's good to know. I'll try updating the firmware on the miners with the USB connections tomorrow. Only problem is I don't have a Windows PC. Well, I have a PC running Linux, and I do have a Windows 7 disc so I guess I could install it but I don't want to if I don't have to.

The installation instructions say: "The next value is the number of miners, this must be the total number of chips in cluster multiplied by 2 (32 for 16 chips or one board)." so wouldn't it be 256 for a stack of 8 boards (8 * 2 * 16 = 256)?
To update firmware from Linux, you can try using pic32prog. Some modifications are required: see I have made those changes in After compiling it, power-on the boards and run "./pic32prog <hex file>" within the 12 second bootloader window.

About the "multiplied by 2" thing, that's a relic from when an input queue was introduced (you needed to multiply the actual number of miners by 2 to compensate for the input queue). cgminer versions >= 3.4.0 do not need the multiplication by 2. I think that instruction is there to account for people using older cgminer versions.
10  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 11, 2013, 03:18:17 AM
When trying to connect boards with the CAN-BUS cable, I frequently get errors like:

[2013-10-10 18:38:49] BTB0: Comms error(buffer)
 [2013-10-10 18:38:49] usb_write error on avalon_write
 [2013-10-10 18:38:50] usb_write error on avalon_write
 [2013-10-10 18:38:50] usb_write error on avalon_write

It seems ot be kind of random. I've trying every combination of 2 - 8 boards that I can. The only thing consistent is the first and last boards. Sometimes it works, sometimes it doesn't but it is repeatable. I haven't been able to get more than 4 boards working at a time. But not always the same 4 boards.

What could be going wrong?
Are you using the latest firmware ( This firmware deals specifically with a "CAN-BUS causes usb_write error" issue. It only needs to be written onto the USB-connected boards, so it's okay if the CAN-connected ones aren't updated.

I really have no idea what the correct CGMiner options should be though. The "number of chips" option doesn't seem to do anything at all. Right now I have 1 cluster of 4 miners and 4 single miners all connected in cgminer.


What does that "number of chips" setting actually do?
The baud rate, number of chips and timeout are all ignored (they're vestigial from the Avalon-based BitBurners). The number of miners should be 16 * number of boards in the largest stack. Since you've divided your stack up, it should be 64. But if you had all 8 boards in a single stack it should be 128. It's okay if the number of miners is larger than necessary, though you might get a slightly higher stale rate due to cgminer queueing up more work than necessary.
11  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 10, 2013, 05:11:22 AM
That's great to hear! Now I just got to get my hands on a CANBUS cable I can run my 3 damaged boards. Someone here is selling me an extra one but its going to be rough waiting till next week to get it.
I wish I knew the specs on the cable and connectors so I could just overnight one from Digikey. I might just take a guess and order some parts and anyways and see if it works.
The cable should be a straight-through (pin 1 to pin 1, pin 2 to pin 2, ..., pin 10 to pin 10) flat ribbon cable with 0.05 inch pitch. If you have one with >10 wires, you can just tear off all but 10. The connectors should be female sockets, 2 rows of 5 pins, 0.1 inch between each pin (you probably already knew that from looking at the board), IDC termination. Something like this: should do.
12  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 09, 2013, 05:02:57 AM
Ok so I am having issues with my single board, its hashing around 30 GH/s.

1) using firmware BitBurnerFury_08.10.13
2) using someone42's latest git that Burnin posted, compiled in ubuntu 12.04.3
3) ./configure --enable-avalon --enable-bitfury was used in compiling
4) adequately cooled and powered
5) 90-95% HW errors on newest firmware/cgminer and older stable versions

Any idea what could be wrong?
What voltage/frequency settings are you using? Setting too high a frequency can cause close to 100% HW errors. Also, it is normal to see a huge rush of HW errors just after the board is power-cycled. Eventually (after ~1000), the rush should stop. To make accurate HW error measurements, you should restart cgminer, or zero statistics ('d', 'z') after the rush.
13  Bitcoin / Hardware / Re: What ever happened to Butterfly Labs' BitSafe Wallet ? on: October 09, 2013, 04:49:30 AM
The BitSafe hardware wallet is an open-source project. It did not originate from BFL (see for the hardware side and for the firmware side), though BFL are the ones commercialising it. Like many open-source projects, work was done in our (allten and I) spare time, on a purely voluntary basis. Since we have other things going on in our lives, sometimes that means that development stalls. Currently, development has stalled. I expect things to pick up in the coming months as I have more free time.

[who the fuck cares]
You may not find a hardware wallet useful. You are probably competent at computer security. A hardware wallet will not offer you much additional security. But what about "ordinary people", who may not be as well-versed in keeping their computers secure? How are they supposed to store and use their BTC? Hardware wallets like the BitSafe and Trezor aim to improve wallet security while remaining useable by ordinary people.
14  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 08, 2013, 11:19:29 AM

AFAICS there are changes in the way voltage selection is done in this new driver.

I think you now specify the true voltage with a new argument, i.e. for standard (not overvolted) operation:

--bitburner-fury-voltage 900

But I could be wrong.  Hopefully @someone42 or @burnin will confirm soon.  Until then I suggest caution.

The --bitburner-fury-voltage option will only take effect if a board identifies as BBF (as opposed to BTB) in cgminer. The current firmware will always identify as BTB, although getting it to identify as BBF is as simple as changing the USB product string from "BitBurner" to "BitBurner Fury".

I'm going to hold off on changing the USB product string until pull #499 makes it into an official release. This is because changing the USB product string will stop the boards from being recognised by older cgminer versions.

Yes, this is a bit of a mess. But hopefully in a few weeks time, everyone will be using new firmware and new cgminer which will render all this "add 300 mV to the desired core voltage" business obsolete.
15  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 07, 2013, 10:56:36 AM
Can you provide a working rasp image? this might help ...

I have no problems running the bitfury miner on the pi with the image "2013-07-26-wheezy-raspbian.img". Did you try another USB Hub?
I compiled cgminer 3.5 with options "--enable-icarus --enable-bitfury --enable-avalon".

But the board only does around 40-45 Ghash/s. That's really disappointing.  Sad
My options are "--avalon-options 115200:16:10:d:256 --bitburner-voltage 1230".

You could try overclocking and overvolting. I believe the maximum is 1100 mV (i.e. --bitburner-voltage 1400). You would need to do some testing to see what the optimal frequency is, but I think something around 300 MHz is achievable (based on the prototype that I have).

I should expand on what I said before. Theoretical hashrate is 11.63 * frequency, per chip. So for example, at 256 MHz, that's 2.98 GH/s per chip or about 47.7 GH/s per board. A frequency of 300 MHz corresponds to 56 GH/s per board.
16  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 07, 2013, 08:14:34 AM
Getting a USB write Error ...

I don't know what version of firmware you're using, but try using this one:

For instructions on updating firmware, see:
17  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 07, 2013, 07:54:40 AM
arrived ...

can anyone give a short info ... about parameters for the bitburner fury? ... for cgminer?

Is the avalon stuff valid for BitBurner Fury too?

Try this:
./cgminer --config <insert pool config file here> --avalon-options 115200:16:10:d:256 --bitburner-voltage 1230

Here's an explanation of the avalon-options parameter:
  • 115200: baud rate. Ignored by firmware.
  • 16: number of miners. Set this to 16 * number of boards.
  • 10: chips per miner. Ignored by firmware.
  • d: timeout. Ignored by firmware.
  • 256: frequency. This sets the frequency of the external clock. The theoretical hashrate is 11.63 * frequency.

Like with the BitBurner XX boards, --bitburner-voltage controls the core voltage. However, since BitFury is 55 nm instead of Avalon gen1's 110 nm, the actual core voltage will be 300 mV less than what you set here. So "--bitburner-voltage 1230" will set core voltage to 930 mV. (Future versions of the firmware/cgminer will probably use a different identifier to avoid confusion.)

It is normal to get hundreds of HW errors/duplicate work on the first run after power up. This is a firmware bug. It should resolve itself in 30 seconds. If you do want to get accurate measurements of HW errors, run cgminer for 30 seconds, then restart cgminer.
18  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 02, 2013, 03:21:46 PM
Wow, that sounds great. I guess this means you can put both Bitburner XXs and Furys to the same CAN-bus and control all boards from one cgminer :-?
In principle, yes, since the CAN-bus protocol is also the same. But in practice, you will get HW errors because of how cgminer's Avalon driver is implemented*. Also, frequency settings are broadcast across the CAN-bus and it's unlikely that you would want Avalon and BitFury to run at exactly the same frequency.

Maybe in the future, when a well-designed cgminer driver and corresponding firmware is written, you will be able to mix Avalon/BitFury/Cointerra/whatever BitBurner boards.

cgminer doesn't control the voltage of any miner to date.  All existing miners (and almost certainly this product as well) operate on a fixed voltage.  Changing the voltage requires changing a resistor on the board.
Voltage control for BitBurner boards from within cgminer was added in August (see

Thanks someone42, that's just the update we were looking for. This all sounds very positive. So do you have somebody on the team working on the cgminer tweaks, so that we can get hashing as soon as the boards arrive?

*cgminer's Avalon driver rotates through an array of work units. Mixing Avalon and BitFury will cause the array rotation to happen too fast for the Avalon boards, causing cgminer to forget about work units and resulting in "no matching work" errors.
19  Bitcoin / Hardware / Re: Bitburner Fury - Hashrate Protection on: October 02, 2013, 01:03:02 PM
About the software situation, I can clear this up a bit.

Though I am not burnin or cryptx, I am the person primarily responsible for the boards' firmware. The firmware for the BitBurner Fury boards emulates the Avalon protocol, just like the Avalon-based BitBurner XX boards. So there won't be any need for a customised version of cgminer. All the details of BitFury chip communication are abstracted away by the firmware. If you already have BitBurner XX boards, whatever setup you have will be fine for the BitBurner Fury boards.

Some minor changes to cgminer might be required since voltage settings are different (since Avalon = 110 nm, BitFury = 55 nm). Also, since the BitFury boards are much more powerful, some delays need to be adjusted to ensure that the cgminer driver doesn't become a bottleneck.
20  Bitcoin / Development & Technical Discussion / Re: Entropy source for smartphone or HW wallet on: September 23, 2013, 01:53:03 PM
Can we use the accelerometer in smartphone as entropy source (or adding it to HW wallet, costs only about 1 USD)? When generating a new address, or signing, the user is asked to shake the device for a few seconds. That should give plenty of randomness

For HW wallets, there are faster (in raw bits/s) ways to collect entropy for < 1 USD in parts and with no user interaction required. I describe some of them here:, but I am sure there are many more ways. These also have the benefit of being internal, so it is more difficult for an observer to guess the state of your entropy pool.
Pages: [1] 2 3 4 »
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!