App nap was not disabled.  But now it is.  Thanks.  I was plugged in the whole time, it would be slightly strange for process to be throttled in such circumstances, but I suppose there is the issue of heat buildup, and maintaining UI responsiveness in the foreground.  I'll see if it makes a difference.


I guessed that as well.  That is why I isolated my systems form the internet, and made them connect to each other.  Both have fast SSDs.  The bottle neck really should have been the CPU in the bootstrapping machine.

I controlled some variables and the problem still persisted.

I set still client that is still bootstrapping to connect=192.168.1.100, that being the static local address of another computer running a full node.  It certainly pulled in the blocks fast, at about 1 MB/s.  That only for three minutes or so before the sync ground to a halt.  I restarted the program, and sure enough, another solid run of data transfer, maybe for six or seven minutes, then it stopped.

Here is a graph of my CPU.  It shows about 30 minutes of history.  Bitcoin was the only thing running.  I quit the program twice and restarted twice over the course of the graph.  It let the computer idle for a minute in between.  Starting from the left, about 20% into the graph, there is a short lull, followed by the biggest chunk of CPU thus far.  That was when I restarted the client.  Then there is a break in CPU effort, after the client has started, but before it was crunching blocks.  Then there is a period of block processing, before it reverts to a very low intensity state, with not much syncing.

After ~8 minutes of mostly idling, I restated again (the middle point of the graph).  The same pattern repeats, though this time it processed blocks for ~7 minutes or so.




I even unplugged the WAN cable.  Each client showed one connection, one outbound, one inbound.  They were just talking to each other.  Again, the syncing went fast for a few minutes, then mostly stopped.

I have seen basically the same behavior just running the client stock, connecting to larger bitcoin network, and running it modified, to only connect to local hosts.

The blockchain synchronizes quickly when Bitcoin Core is first started, but after some time, maybe an hour or so, it slows to a crawl.  I can’t find the bottle neck.

This behavior is occurring under good testing conditions.


Computer: MacBook Pro 3.1, 2.4 Ghz Core 2 Duo, 4 GB RAM, 250GB SSD

OS: Mavericks 10.9.5 - Clean Install.  Bitcoin Core 9.3 is the only non-packaged software.

Internet: 25 / 5 mbps cable (comcast).

All settings are essentially stock.  I turned on the software firewall, then turned it back off.  Filevault 2 has been activated.

Description:  I did a clean install of the OS last night on a brand new hard drive.  I encrypted the drive and immediately proceeded to download Bitcoin Core 9.3 to test it out, and to test out the current blockchain total download time.

The client has been running for about 7 hours now, and currently has 16 inbound and 8 outbound connections, but it seems like nothing is happening. The block count in the debug window hasn’t budged in 5 minutes

CPU is 80% idle.  RAM is only about 50% full.  Network - 20 KB /s.

Then, as I am writing this, the data rate flowing into the computer surges to ~1.0 MB/s, the CPU starts processing, and the block count is flying upwards.  It is currently requesting blocks from September, 2011 era.

Now, just a couple of minutes and 1,000 blocks later, the computer is receiving only ~50 KB/s, the CPU is idle again, and the block count is not increasing, not even slowly.  It is stuck at block 143,882.

Next I quit and restart Bitcoin Core.  Almost instantly blocks start processing again, and downloading at 500 - 1,000 KB/s.  Within a minute or two, it has 1 inbound connection and 8 outbound.

I have observed the same thing happening on other Macs running 10.9.5.

Does anyone have a good explanation for this behavior?  It almost seems like my client just happens to be connected to 8 peers, none of which are willing to share any blockchain data.  If that is the case, I am surprised it wouldn’t do a more active search for sources of fast blocks.

I agree that radioactive decay is random, but am pretty sure that detecting an emitted photon or particle is a one-time thing.  I don't think it is possible to have two Geiger counters register the same event.  So you would have to trust the Geiger counter is working as described.  And would you trust a fourmilab device if I told you they were actually a front for the NSA?

There description of timing, that is exactly what I have mind.  The main difference is the design I propose allows for multiple observer systems.

I could use some assistance with this project.

•Technical expertise with the timing system - I need a way create a timestamped record of the blinking led.  I have never used any kind of direct ADC feed before, so any advice would be helpful.  24 bit, 1 MHZ minimum.  But... I only need data sent to the computer when there is a change of state of the photodiode, and all that data needs to be is [ON or OFF] and [timestamp to 1 microsecond] .  Over USB would be great!


•Does anyone have ideas about a better place to post this and get feedback?


•Please give ideas about how to accomplish something as secure, but smaller and with a high data rate.  Better kbit/s to m³ ratio


•This will be proof of concept / development prototype.  Hopefully the design can be optimized so it can be a workable solution for people critical security needs.

A Proposal for a Trustless Hardware Random Number Generator

Overview

All of the hardware random number generators I am aware of, even the allegedly “crypto secure” ones, appear to rely on the integrity of their integrated circuits.  I don’t think it is reasonable to trust any particular integrated circuit for mission critical security.  With deterministic processes, it is easy to avoid trusting specific hardware by executing in parallel and checking the results against each other.  A simulation could be run on ten separate, air-gapped computers each using different operating systems, each having been made by different hardware manufactures and each running the simulation on different implementations of the same ‘protocol’.  All results should agree.  The chance of an attack affecting all ten systems, in such a way that they all give the exact same bogus result, is vanishingly small.

Traditional hardware random number generators, non-deterministic by design, cannot have their results audited in a similar way.  The user is left to trust that the hardware functions as advertised.

The kind of trustless HRGN (TL-HRGN) that I have in mind must somehow separate the source of entropy from the digitization process, such that there can be multiple computer-observers of the same physical event.  Ideally there could be as many isolated computers as the user wanted, each recording the same phenomenon – say dice rolls - and afterwards comparing results.  The results should match.  The user would still be responsible for making sure they had fair dice – a much easier task than making sure an I.C. doesn’t have a backdoor.  In addition, each of the separate computers could be running statistics on the dice-generated entropy to make sure it met tests for randomness.

***********************************************************************************

Design

I am currently working on a TL-HRNG design for which I intend to construct a working prototype.  Design goals are as follows:

Size:          Desktop computer tower-sized or smaller
Data Rate: At least 500 bits of entropy per second. 10kbits / sec would be better
Cost:         Under $2,000 - under $500 would be better

The randomness will be motion-based, using BBs or ball bearings that cascade down from the top of the device, sliding and rolling down an inclined backboard.  There will be some ramps to limit and roughly control the flow of the bearings.  There will be sensitive electrical switches placed in locations where bearings will frequently strike.  The switches will be designed such that when struck with a bearing, they will close only momentarily, hopefully something on the order of 0.1ms.

{Insert Picture of spring-switch}

A switch will be wired to a battery and light emitting diode. Every time a bearing strikes the switch surface, the connected LED will blink.  A photodiode, connected to a high-speed analog to digital converter, will look directly at the LED.  The quantity to be measured will be the time between blinks, hopefully to the millionth, or even ten-millionth, of a second.  The high precision is important.  The data will not be random, and therefore not useful, until at least several positions to the right of the decimal.  At the same time, the data can only be considered trustless if at least two independent computer systems can agree on their observations.  The closer the agreement - in terms of time measured - the more useful bits of entropy that can be harvested per event.

Since the two computer systems are isolated from each other, they will not have any kind of clock synchronization.  Perhaps to within a second or two, as that could be accomplished by manually setting date and time, but that is not going to help with the required micro-second precision.  The idea is each computer will have a list of time-stamped events.  While the time-stamps themselves will not match, the elapsed time between events should be the same, at least to some level of precision.

This should be possible to accomplish with any number of isolated computer systems. The only thing the computers have common is they are all staring – via separate photodiodes – at the same blinking LED.  The LED blinks when cascading ball bearings strike a switch surface.  A trustless hardware random number generator.

**********************************************************************************

I was inspired by the Dice-O-Matic (http://gamesbyemail.com/news/diceomatic).  It is an automated dice rolling system.  The dice are rolled by tumbling down a curved chute.  At the bottom they settle into an elevator system for ride back to the top of the chute.  As the dice ride the elevator, a camera snaps their picture, and the dice markings are analyzed with software.  While the ingenious creator doesn’t indicated having multiple cameras and computers to corroborate each other’s record, they would be trivial to add.

I totally agree with this, and it is the dominant factor that is currently holding down the price.  But the relative expansion (the inflation rate), is still meaningful.  I don't know how to construct a model that gives appropriate weight to each variable.

So you also compensated for the faster rate of block issuance?  Glad someone double checked my work.  I came up the 15% figure just by eyeballing the chart, and I forgot that "halfway" in distance between two ticks on a log scale is not halfway in numbers.  So I can see the 12.75% being the correct value.  If anyone wants my R code, to review or modify, just PM me.

You guys are missing the point of the graph.  I am not trying convince anyone that 3 million coins are lost.  I do, however, find it a plausible upper limit, and that is why I bothered to make the chart.  The truth is somewhere between the black line and the blue / red.  Of course no one knows the exact number of lost coins.  It would be cool if the chart was interactive, and you could easily enter your own assumptions for the amount of lost coins, and see how that effected the inflation rate.

Also - would any of you care to put forward your own estimates for how many coins have been lost?

Current BTC inflation could be closer to 15%, rather than the 10% suggested by the chart in the OP.  I made a similar chart, and gave it a separate thread https://bitcointalk.org/index.php?topic=800890.0  It factors in an assumed 3,000,000 lost bitcoins, as well as actual block time being under 10 minutes.  The 3,000,000 lost coins comes from the Zombie Bitcoin analysis.

Tying up, or encumbering one's own funds is and would always be a personal choice.  With freedom comes the freedom to make bad decisions.  It would be up the owner to weigh the pros and cons of trying up the funds.  It sounds to me like you are saying the 'problem' would be people making a choice, and then later regretting it.  Or am I missing something?

I agree.  But we do know with certainty that *some* have been lost, so the question becomes 'how many?'.  The Zombie Bitcoins article had a clever method for making an estimate, so that is why I used the 3 million figure.

I proposed almost the exact same thing in this thread: https://bitcointalk.org/index.php?topic=511881.0;all
At first I titled the thread Transaction reversability would be a good thing, but I some point I realized people were not even reading the original post, and they were just attacking the idea on the title.  That's when I changed it to Transaction reversability would be a BAD thing.

I was inspired by whitslack's nice Bitcoin inflation charts, found here https://bitcointalk.org/index.php?topic=130619.0.  I wanted make a similar chart, but one that included John Ratcliff's estimates on lost, or "Zombie" bitcoins.  The Zombie analysis can be found here http://letstalkbitcoin.com/blog/post/rise-of-the-zombie-bitcoins.  I used R to make the chart.  It was my first time using R and it took me all day!



If in fact 3 million coins are not controllable, and therefore effectively out of the current supply of bitcoins, the current inflation rate is closer to 15%, which is 50% higher than the 10% that would otherwise be expected.  The results are interesting and the graph speaks for itself.

I would be interested to see this chart with two correction factors applied:

1) Actual block frequency data used for 2009 - present, or at least a weekly average or monthly average.

2) A adjustment subtracting the supposed 'Zombie Bitcoins' from the supply.  The inflation rate would be: rate of new coins / (total coins - zombie coins to date)

These adjustments would suggest the current inflation rate to be higher than the graph indicates.  However, the new graph should also show the rate getting lower at a faster pace.

Does anyone know how the above graph was produced, or some good software to make something similar?  I tried to implement my proposed modifications on Excel, but decided there must be a better way.

I think it was worth watching.  He was basically saying that right now bitcoin is not really money, but he left open the option that it could become more money like as volatility decreases, more people and companies accept it, and the usability and security of wallets improve.  He has a team of students doing bitcoin research.  I think he gets it.

I used a Liberty Teller atm in Boston's South Station.  Just $5 to see how it worked and to show my support for the guys running it.  Had a good conversation with them too.  I can't remember exactly how much the fees were; since it was $5 I didn't really care, but I think it was something like 5%.  Competition will drive down the fees with time.

I also was given a person demonstration by one of the SkyHook creators before they hit the market, and in that instance I only put in $1.  It is a sweet little machine and I am happy to hear that SkyHook's are flying out the door.  They basically made the ATM as small and inexpensive as possible, and at the same time were the first company to open-source the software. Go LiberyTeller! Go SkyHook!  Go Tim! 

Agreed.  I can't see any reason why an insurance company would be willing to insure bitcoins that were under a private individual's sole control, and I can't really see a reason why there is a need for that, considering how easy it is to transfer and share BTC ownership.

My idea for semi-distributed cold storage insurance would be along these lines:  Lets say you own a house worth $1,000,000 and you own all of it, no mortgage.  And lets say you are a cold storage ninja.  You could sign a contract with an insurance broker to store bitcoins worth up to 1/3 of the house value.  If you couldn't or wouldn't give back the coins according to the terms of the contract, the house would be liquidated and converted to BTC to repay the person who had paid for the bitcoins to be stored and insured.  The 1:3 btc to house value-ratio is just a guess on my part, I don't know what the optimum would be.

No LiteCoins?

Yeah, this article is a load of crap.  I read through the whole CFPB guidance, and I suggest you do the same, very carefully.  The governments position is largely neutral, with some factual errors and some bitcoin-negative bias.  But, reading the news coverage of the government report, one would be led to think the government said "Warning: Stay Away".  In fact, the report was much more in the direction of "Bitcoin: Here is what you need to watch out for if you want to safely engage"

The government report is actually an opportunity for us.  It sets a minimum for FUD.  Any journalist that is more negative and less informed on bitcoin than the government, we have something "official" we can use to refer them to.

 Here is an except from the CFPB report:




This is what I wrote to Michael Hiltzik, the author of the LA Times piece:


He brushed me off with a link to the CFPB report, which I obviously had already read.