I'm wondering what would be an optimal use of the demo unit after Bitcoin Foundation posts the review. Auction it? My guess is that someone stateside would be willing to pay a premium to be able to tear down the unit for truely in-depth review.

I apologize I wrote like everyone knows and understands the postmortem debugging.

$ cat bitcoind.c
#include <stdio.h>
int main() { return printf("Hello %s!\n",2112); }
$ make bitcoind
$ ulimit -a
core file size           (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
$ ulimit -c unlimited
$ ulimit -a
core file size           (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
$ ./bitcoind
Segmentation fault (core dumped)
$ ls core*
core
$ gdb ./bitcoind core
GNU gdb (GDB) 7.1-ubuntu
Reading symbols from /home/2112/bitcoind...(no debugging symbols found)...done.
Reading symbols from /lib/libc.so.6...done.
Core was generated by `./bitcoind'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f4f24cd7e32 in _IO_vfprintf_internal (s=0x7f4f2500c780,
    format=<value optimized out>, ap=0x7fffcba92680) at vfprintf.c:1617
1617   vfprintf.c: No such file or directory.
   in vfprintf.c
(gdb) where
#0  0x00007f4f24cd7e32 in _IO_vfprintf_internal (s=0x7f4f2500c780,
    format=<value optimized out>, ap=0x7fffcba92680) at vfprintf.c:1617
#1  0x00007f4f24cdf65a in __printf (
    format=0xffffe906 <Address 0xffffe906 out of bounds>) at printf.c:35
#2  0x000000000040053f in main ()
(gdb)

So on a reasonable OS program doesn't have to be compiled with debugging and/or run under the debugger to approximately locate the place where it crashed.

I think that it is a terrible legacy of Microsoft (and/or Apple) that various Linux distributions switched to "disable core dumps by default". The old "remove core dumps older than a week by default" was much better, because nobody would use the "program crashes, but not under the debugger" excuse.

Again, I want to apologize for writing like everyone already knows and just needed a reminder. Hopefully there will be at least one reader who wasn't familiar with the postmortem concept who now will learn how to override the default in their Linux installation to re-enable to perform good old core dumps. Nowadays core memory can probably be found only in museums, but the core dumps are still useful. Lets debug like it is 1970 again!

I just wanted to remind you about "ulimit -c unlimited" to be able to meaningfully use the debugger after the crash. You're probably running with the default of "ulimit -c 0".

I'm not sure I understand your question. The inter-event time for the Poisson process has http://en.wikipedia.org/wiki/Exponential_distribution . Are you talking about something else?

The required rate would need to be about 0.33 Mbps. For comparison: a perfect stereo CD-quality audio over S/PDIF or TOSLINK is about 1.41 Mbps. For another comparison: standard serial ports support up to 115200 bps (0.11 Mbps).

So this isn't impossible, but will be somewhat hard to achieve.

Telephone modem code base will not be immediately useable because it is designed for 8-bit nonlinear quantization, sampled at 8 kHz and a single pair of wires for both directions.

The typical audio line-in/line-out ports would support 48kHz sampling, 16-bit linear quantization and a separate wires for each direction.

Maybe this board is read by a telecommunication student who may have SDSL modem source code handy and be willing to downrate such a code to 20kHz audio band and is not bound by 3rd party licensing requirements.

Two possible ways forward:

1) try to integrate some amateur radio code like http://en.wikipedia.org/wiki/WSJT_(Amateur_radio_software) . There are several people here who could advise you how to modify it to take advantage of wider bandwidth, much better signal/noise ratio and no multipath/echo.

2) see if you can write on your own a code to generate a 10kHz sine wave and a code to receive it properly at -3dB with AGC (automatic gain control). If you manage that then again this board has enough people familiar with amateur radio to advise you how to implement simple QAM channel (Quadrature-Amplitude Modulation). It shouldn't be that hard to reach somewhere between 1/10 and 1/3 of the bandwidth you originally asked for.

In my humble opinion the most work will be related to integration, not actual DSP. Things like: which of the several standards of audio drivers to use; how to detect available drivers; how to control output volume to avoid distortion; how to control input volume to avoid both noise and distortion. And last but not least: how to disable various sound effects, pseudo-3D audio, super-bass, etc.

Ah, the obligatory visit from a silver-bullet salesman. This year's it is arturh selling Haskell. Last year it was Vandroiy selling aspect-oriented programming.

https://bitcointalk.org/index.php?topic=30200.msg614861#msg614861

It is fun to re-read the posts from late 2011 entitled "Request for Standarization". The more things change the more they stay the same, or in its original French "plus ça change, plus c'est la même chose".

Check out how etotheipi changed from 2011 when he was "out-of-core" to 2013 when he is almost "in-core".

Check out how my lame attempts at satire or Commedia dell'arte didn't change.

If we can't get an official Bitcoin standard can we at least find an official Bitcoin core development jester?

OK, I think I now understand our miscommunication.

I don't disagree that the "same security level" can be achieved with better time accuracy. I agree on this point.

What you seem to be missing from my point is the mathematical beauty of the "abstract time measured by the proof of work". The rules of Bitcoin have a beautiful property of statistical resistance to all kinds of cheating unless done by the 50%-or-more majority. No minority group can subvert this mechanism by coordinated cheating with timestamps, neither by moving block time forward nor backward.

So the single technical mechanism guards both honesty against double spending and against false timestamping. You may think that this is too complex; but I think it is mathematically minimal. In my opinion what you propose makes the Bitcoin more mathematically complex with unclear financial benefit.

Everyone here knows by heart that Satoshi considered transaction "confirmed" when it is 6 blocks deep in the blockchain.

Can you see the beauty of the fact that it takes 6 blocks to recognize that the time-on-the-blockchain moved forward? 6 blocks is measured statistically as a median-of-last-11-blocks. Anything less than 6-out-of-11 blocks wouldn't move the time forward! If it wasn't a median-of-11 but say average-of-11 then the time would move by an equivalent of increasing transaction confirmations by a fractional number.

6 may be an arbitrary number. 11 only looks arbitrary. It is actually dual to 6 by the duality of blocktime vs. blockheight. So if somebody proposes to change 6 without the corresponding change to 11, you now know that that person didn't really understand Bitcoin.

Yes, Satoshi could write this explicitly in his paper. But he probably set such a trap to allow himself to quickly grade the proposed changes to Bitcoin. So be aware of this when you making your own proposals.

It's not your job? Dude, it wasn't Satoshi's job either. But he designed something intellectually consistent: abstract block-time, completely self-contained and discoverable by looking only inside the blockchain and only backward.

What you doing is just digging your own intellectual grave: flogging the hobby horse of parts-per-million clock accuracy and not showing any understanding of how abstract-but-cryptographically-secured time allowed Satoshi to make mathematical guarantees of security and convergence.

Please post something that shows that you understand how time-invariance of blockchain verification contributed to the security of the Bitcoin protocol.

I kinda agree that some design assumptions are ridiculous. But the design is a community-supported effort, and there are many people on the Internet who subscribe to very strange ideologies.

One of them is that some goverment (probably USA) will subvert all observable time sources (NTP, GPS, etc.) yet the Internet will continue to operate. This is completely ridiculous, as vast majority of the modern digital communication is synchronous and relying on the precise clocks that are satellite-synchronised. Just check out the post above by retep; or earlier posts by gmaxwell or Hal. I find this level of misunderstanding of modern communication technology fairly prevalent, just check out this recent thread. https://bitcointalk.org/index.php?topic=133445.0

When you understand this bunker-level of paranoia you'll also understand the design choices for the Bitcoin time algorithm. It continues to operate in completely off-line mode underground or underwater, where you get to synchronize your blockchain by carrier-moles or carrier-dolphins. I can clearly admire the ideological consistency: the function "valid(block,blockchain)" is a pure function that depends only on its arguments, not on a implicit, side-channel access to a trusted time source.

The other side of this argument proposes two algorithms: one real-time (for "current" blocks) and one past-time (for "historical" blocks). I have yet to see anyone who proposed a single contiguous algorithm which will reject the same blocks both when seeing them on the p2p net and when verifying the stored blockchain. Can you write a proof that your pure function "valid(block,blockchain,t)" is both independent of the "t" parameter and somehow better than the old "valid(block,blockchain)" function? And for what definitions of "better"?

This reduced-sanity mode is there to allow a part-time on-line/part-time off-line operation. You'll need to come up with a better sanity checking that doesn't require full-time on-line operation and doesn't create orphaned sub-chains when coming up online after a downtime.

What's with that "losing money" FUD? As far as fixing OpenSSL I understand that the existing blockchain would fail the self-test. So the outcome would be that nobody using Satoshi's client would upgrade until core developers come up with an explicit way to reproduce the old OpenSSL bugs. Is that what you are afraid of?

Anyway, weekend is a good time to post my favourite picture of an amber.

Check out the posts by bitfury. He was/is offering such design for sale.

https://bitcointalk.org/index.php?topic=83332.0

http://www.bitfury.org/bitfury110.html

http://www.bitfury.org/xc6slx150.html  <- the planahead porn is here

Briefly: almost everyone is offering the unrolled designs because the rolled sea-of-hashers design hit some worst cases in the synthesis/place/route toolchains: they either fail to converge or converge to shamefully bad implementations. Any practical implementation would have to utilise some sort of workaround for the toolchain's lack of convergence.

I believe that the most recent/fastest bitstreams from ngzhang are also closed-source because of the effort he had to expend to successfully implement them. The default Xilinx ISE wasn't cutting it anymore.

Smalltalk blue book is a beautifull example of how to write a great specification and simultaneously how to lose money on a business venture. The book(s) are just beautifull; but the business was really nasty: Xerox jeaously guarded the trade secrets and copyrights and demanded tremendous royalities and fees. Even after the Smalltalk died as a viable business competitor Xerox lawyers with great effort guarded the copyrights for what essentially was an abandonware. Thus came Squeak: a clean-room legaly-unimpeachable re-implementation to avoid paying Xerox.

With the business advice like that Bitcoin doesn't need enemies.

More work, praise for work, and respect from work to the core development team. In the absence of the usual, salaried work arrangement respect is about the only motivating factor everyone can count on.

There is a problem with the alternative compensation schemes: big payoff after successfull delivery: it works for well managed IPO or well executed long con.

I think that the fixed specification is not a worthwhile goal. The goal should be to establish a protocol management organization that has inclusiveness written into the statute.

But in order to achieve the above Bitcoin millieu would need to have a credible economic force to counterbalance the American-Japanese coalition that currently steers Bitcoin.

It would be very easy to completely derail the specification writing by overdesigning it or overformalizing it. I'm somewhat familiar with the infamous history of the VRML (Virtual Reality Modeling Language) that Gavin Andresen co-authored. It was primarily developed by the consortium of hardware manufacturers with very little input from the primary users of modeling: 3d sculptors, graphic artists, industrial designers, etc. VRML became an idealized superset tool that wasn't really supported by the actual tools used in the industry from Wavefront, Alias, Softimage, etc. It appealed only to programmers and probably to hardware vendors.

Decent brief on the historical context can be read here:

https://design.osu.edu/carlson/history/lessons.html

in sections 7 and 8.

So the VRML misdesign equivalent would be to design Bitcoin according to the needs of cryptographers and programmers to the detriment of accountants and other users of financial software.

Do you recognize the similarities to the current situation?

Anyway, to have a credible standarization effort you'll need cash flow to support it. There is very little point in comparing it with efforts like HTTP or VRML or other "(say > 100 devs and say > 100 million USD)" undertakings. I don't think that there won't be much benefit to it unless there is at least 4 people drawing 4 salaries doing full-time Bitcoin development. I don't think Bitcoin is at this stage yet.

I'm sorry, but your reality check just bounced. Two example scenarios where this could happen:

1) major brand does outsourcing deal with a non-brand where the value of the contract is set low because the sub-contractor relied on the non-traditional sources of income.

2) major brand does layoffs and the employes push an update with accidental-on-purpose exploit that facilitates this type of theft.

If the brand is really major you can count on no-expenses-spared PR campaign to cover up such missteps.

Those scenarios aren't theoretic, paranoid speculations. Those are things that did happen to e.g. Hewlett-Packard and probably many others.

I have the following proposal: give away certain small fixed fraction of foundation coins to the same addresses that were used by original miners of the original blocks. This would test the technical skills (programming and system administration) of the miners. The grants that would not get redeemed will signify an abandonware miner.

This grant should automatically cease once the technical skill required to redeem this grant becomes nearly universal.

Perhaps if you post an example of a specification that is both "formal" and "easy for anyone" we could make a better comments. Common way of thinking leans toward saying that those are polar opposites.

Anyway, the major points against are:

0) extremely expensive
1) a lot of work with comparatively little benefit
2) hard to prove internal consistency
3) hard to verify consistency with non-formal, but actual implementations

When asked for pitfalls of "formal modeling" I nowadays point towards the ARM Architecture Manual and the way how multi-million company with clearly clever and well motivated staff ended up with BE32 and BE8 (a.k.a. just plain BE): two largely incompatible ways to implement big-endianess.

So how do you call the hard fork that occured after a fix to the integer overflow issue?

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139

Obviously the biggest constraint is time-to-market or time-to-mine.

Wouldn't it be practical to keep all PCB layers clean under the ground paddles; use a hole punch to cut out the PCB epoxy under the chips and mount the real heatsink on the bottoms with copper washers/thermal spreaders? The tops would then just need a mechanical clamp.

I'm just brainstorming. I made a suggestion about 5 months ago about using power IC packages in this thread: https://bitcointalk.org/index.php?topic=91173.msg1062969#msg1062969 . friedcat responded then immediately deleted his response because it probably disclosed something NDA-embargoed.

But are they going to help? BGA cases are flip-chip; with chip substrate connected to the top of the case.

QFN packages don't flip the chip and actually have air between the top of the package and the chip, because they need to accommodate the bonding wires. They really want to be cooled through the bottom of the PCB because this is where they have the least thermal resistance and a biggest piece of metal: ground connection for the substrate.