It isn’t assumed that the “digital prospectus” remains constant throughout the whole lifetime of the “digital financial security”. The “root prospectus” will be included in the root signature block. The implementation will provide a means of recording the “digital prospectus amendments” which in effect will patch the original prospectus. Throughout the lifetime of the “digital financial security” there will be many forks and joins in the DAG (directed acyclic graph) of the prospectuses. The acceptance of forks and joins will be left for the approval of the end user. In case of the competing forks it will be up to the end user to decide whom to trust. The choice needs to be made only when transacting, the peer can participate in multiple simultaneous versions of the amended security. There will be an obvious overhead of the storage and network bandwidth, but the user will not have to make any either-or choices unless actually transacting.

On the network transport layer the peers will locate each other using a DHT (distributed hash table) using both “root prospectus hash” as well as an ordered pair of the “root and amended prospectus hashes”. I don’t envision that the peers in the proposed protocol would need to shun any other peers. The peer-to-peer network will resemble more of Bittorrent peer-to-peer network: all peers share the DHT and make direct connections only when interested in the sharing of the particular torrent.
 
The “digital prospectus” moves the Bitcoin from the equivalent of the “oral contract” to the equivalent of the “written contract”. In the current implementation of Bitcoin there exist an implicit trust in the “core developer team”, their “Satoshi client C++ implementation” and the “consensus of the majority of the miners”. The proposed implementation would spell the requirements exactly and would allow continuing trading of the instruments among those who do not want to trust the consensus of the majority and any future amended prospectuses.

In other words it would change the Bitcoin government from the democracy to the republic.
The last but not least change allowed by the existence of the “digital prospectus” will be the change in scripting engine. Currently Bitcoin uses a simple postfix script language implemented as an automaton with a stack but without loops. The “no loop” requirement was to avoid possibly of attacks by infinite loop. I propose that the same programming language that is used to represent the digital prospectus is used to represent the scripts. If the prospectus writer decides to allow general scripting with looping she can include in the prospectus a relatively simple theorem prover: given the script and N inputs does the script return true or false in at most K*N steps, where K is arbitrary constant chosen by the prospectus writer. This is not a general undecidable stopping problem because the theorem prover can return “undecided within C*L steps”, where L is the length of the script and C another arbitrary constant in the prospectus. The strong syntax and semantic checker for scripts also has obvious benefits for software testing.

(Continued...)

Bitcoin Improvement Proposal #2112
Ownership: Public domain
Status: Draft ->Deferred
Type: Informational

The purpose of this document is purely informative and not normative. It aims to spread to the wider cryptographic community the various improvements to the well-known Bitcoin design that would address some limitations of the existing implementation that prevent its wider adoption. The proposed changes are far-reaching and as such are not suitable for immediate implementation. They are so extensive that it is certain that a complete reimplementation will be required. No matter what is the immediate fate of this proposal, I’m remaining hopeful that the ideas explained will remain public domain knowledge and will serve as a prior-art counterclaim in any future patent litigation.

The centerpiece of this proposal is the idea of “digital prospectus”: a program whose main functionality is to do perform a verification of the submitted blocks and transactions. This program will be cryptographically hashed and will become a “root prospectus hash” in this proposal and an equivalent of the newspaper headline in the present Bitcoin genesis block. In addition the “root prospectus hash” will become the identifier for the “digital financial security” in the transactional transport protocols. As such it will replace 4-byte integer 1 in the current Bitcoin protocol.

The choice of the programming language for the “digital prospectus” needs to be made early. The primary requirement is that the language needs to have very strong theoretical underpinnings: it must be able to efficiently express its own interpreter and there must be existing programs that are capable of proving simple theorems expressed in this language. It seems to me that some dialect of LISP would be suitable choice. LISP s-expressions maintain very close relationship between the human-readable text of the program (which will be hashed to form the digital prospectus) and the internal data structures that represent the program and which will be interpreted and verified many times during its lifetime. The runtime efficiency is pretty much immaterial; the properties that are tremendously important are (1) well-defined semantics; (2) the ability of the program to analyze and transform its own text; (3) possibility of secure implementations that are resistant to the cryptographic side-channel attacks like “differential fault analysis”, “differential power analysis”, “timing attack”, etc.

The exact content of the “digital prospectus” would depend on the type of the “digital financial security” that it describes. For the security like Bitcoin it would define the rules for the validity of the block and the transaction. It would exactly specify the fees that need to be paid for the inclusion of the transactions in the block and who is allowed to specify checkpoints for the longest chain of blocks. In the current Bitcoin implementation fees are pretty much left unspecified (with the exception of “dust spam defense”) and two block-chain checkpoints were signed by “fabianhjr”, who is pretty much unknown in the community.

(continued...)

I actually find this fascinating: lets compare natman3400's coding skills to the famous xkcd comic site. I presume that xkcd #221 (http://xkcd.com/221/) represents the absolute limit of stupidity that is achievable in the USA. Anybody even little more stupid would not be allowed to graduate.

With the above code as a start I wrote a driver routine to recreate the sample of the same size as the original.
Now just a quick compilation and another test:
And this short test shows that natman3400 is over 4 times (19362/4778) less stupid than the absolute limit of stupidity possible while still graduating normal school in the USA.
There are no more than 3 consecutive zeros in your example file.

People, please keep your bitcoins safe. Don't use Bitclip or any other product developed by somebody who was "bored in [my] Computer Science Class".

Yeah, I downloaded this file just for kicks. My guess of the internal state of the code monkey programmer who created it: disturbed.

Achieving almost 100% compression with plain-old Info-ZIP on a supposedly pseudo-random file is probably going to qualify for the Guinness Book for the World Record of stupidity.

Please, for the safety of your bitcoins, don't use any product offered by the original poster or anything else that he may associate himself with.

http://en.wikipedia.org/wiki/Snake_oil_(cryptography)

Why you insists on calling the unit of time "block"? There is an already existing officially sanctioned SI unit: "decaminute". 

"--server" never worked. "-server" worked and continues to work as far as I can see.

OK, I understand the mis-communication I created with my earlier post.

There are two types of filtering in a typical small-electronics power supply:

1) ripple filter designed to filter out the remnants of the mains frequency and its harmonics

2) switching noise filter designed to filter out the ultra-rapid falling-edges of the reverse-polarization current.

The proper word I should have used is "snubber capacitors" not "filter capacitors".

http://www.hagtech.com/pdf/snubber.pdf

There's a lot of other sources as well, just google "snubber" and "snubbers".

I was thinking of a wall-wart that is more of a recharging device and the ripple filtering is done not with capacitors, but with the battery. It doesn't seem like 3COM manufactures any battery-powered devices, so my assumptions may not apply here.

In the name of science I'm answering:

1) cheap multi-meters measure the average voltage
2) int sin(t),t=0..pi = 2
3) thus peak to average ratio for a full-wave rectifier is pi/2 ~= 1.570
4) 12V * pi/2 ~= 18.9V, 13.5V * pi/2 ~= 21.21V
5) unregulated but filtered power supply will charge its filtering capacitors to the peak voltage in (4)
6) a silicon device designed for 16V maximum input may release its magic smoke if supplied with the unfiltered rectified waveform with peaks as high as (4)
7) if the power supply was first plugged in to the mains side and then to the load side then the filtering capacitors will get partially discharged from the state (5) to their designed average
8) the safer way of powering up is first to plug in the load side of the supply to the device then plug in the supply to the mains outlet.

The above is what science says.

But the whole thread is an example why selling electronics to consumers demands sandbagging: both financial markups to cover losses caused by pissed of consumers and to safeguard devices from the accidental abuse by the uneducated consumers.

I really value your input, but I have to partially disagree with what you wrote.

Conducting business over amateur radio bands is officially prohibited, yet pretty much every QSL request I've seen included "green stamps". Please think of the few bitcoins transmitted a replacement for the "green stamps".

The problems you describe with the path-sensitive reception problems are all related to the non-coherent receivers using crude demodulators. With a mix-signal FPGA in the head-end you could get a phase-coherent rake-receiver working like charm for almost no additional money.

Complementary to the above the synthetic phase-array antenna with some modulation scheme offering LPI (low probability of intercept or low probability of interference) would safeguard the transmitter, again thanks to the mixed-signal FPGA driving the final.

Moreover I'm not advocating breaking any laws. What I'm advocating is a change in the way amateur radio is governing itself. This is the decade of change. AARL and others started dropping the fist & ear CW requirements. And I heard that they reaped the fruit of one of the highest number of new licenses granted in a year. The whole landscape is going to change with the drop of mandatory CW.

Last, but not least: FCC has no jurisdiction over the entire globe. What me (and others) are proposing are way less harmful to all the spectrum users that the current long-distance cordless phone transmissions emanating mostly from CIS and Far East.

Overall, I do believe that the change in the access to the radio waves is possible.

It isn't feasible immediately today. But the feasibility is just around the corner. The main required components would be mixed-signal FPGAs. Xilinx had already started sampling them (Kintex-7) and has plans for even cheaper version Artix-7. Costwise they would be replacement for Spartan-6 family and lower end of Virtex-6 family. Xilinx Spartans is what you'll see both in currently available Bitcoin FPGA miners as well as various commercially available SDRs (software-defined radios).

Mixed-signal FPGAs are what it takes to cheaply commercialize some technologies that thus far were eiher military or research: low probability of intercept, synthetic aperture antennas (nowadays used mostly in radars),  pre-distortion stage to compensate for nonlinearities in linear power amplifiers, etc.

Guys, why going underground and audio waves?

May I suggest that you look up? E-M-E (Moon bounce) is exactly what Bitcoin needs to free itself from the strangehold of the Internet providers. Just come up with the outline of the broadcast protocol for Bitcoin over PSK(whatever) bounced from the visible side of the Moon. Completely untraceable commerce lies ahead.

Even if you don't get a working implementation you'll get a round of applause from your presentation at the next year's Bitcoin Conference.

I tried to plant this idea with Lolcust and his planned money laundering operation with GeistGeld and Tenebrix. But he's more of a graphic designer and you guys have the required amateur radio background.

Support the free trade on Earth by banking on the Moon!

Actually, Lolcust's idea of "The Darkside Transaction Mixer" could be implemented as a literal "Underground" extension to the global Moon-bounce protocol. Use Moon-bounce to relay the transactions above the ground and use the ultrasonic carrier to relay the transactions underground.

Please don't abandon this concept!

https://bitcointalk.org/index.php?topic=46656.msg556294#msg556294

Why signed? The block-chain is already signed beyond all recognition. The blkindex.dat is all redundant information and could be safely recreated on the spot as needed.

Dude, you don't know what you are missing. FPGA programming is like playing a combination of Tetris, chess and contract bridge on a board few millimeters-square, all at the same time. Great fun for the cold winter evenings! The cracks for the FPGA games are available on the usual sites.

Please take your time. I'm not in a hurry. For now I'm playing with LX9 from Avnet doing really simple things to understand the limitations of the current technology.

I also noticed the words "bridal tour" in your edited first message of this thread. If you were just married then congratulations! and really take your time!

Yeah, I have a similar question that is not directly related to mining. I took a quick look at the schematic and noticed that some pins are routed on the PCB to some connector.

Did you do any speed testing on those interconnects? I'm curious about the possibility of connecting the chips for more complex tasks. I see that they are LX150 not LX150T, so no GTP transceivers on them. Am I right?

Well, to offer a "real margin trading" a "real exchange" would have to do a "real credit check". This is where the zhoutong's genius lies. He offers the fake "credit" for the fake "trades" in the currency of the far away land and not the local currency of where he lives. Thus he incurs no credit check expenses whatsoever.

I remember a quip or joke from some experienced broker long time ago. He was asked why the basic of securities and trading aren't taught in high schools. They really are that simple. His answer was "Oh, no! That would kill the markets! There wouldn't be anyone to take the stupid side of the  smart people's trades."

Some people can learn from other people's mistakes that are recorded in books stored in libraries. Other people need to learn from their own mistakes that are recorder in their own checkbook. Which way is better?

I still don't get it. I clearly see "@10/5. (fixed)" in your message. Does that mean that the board was already available since May of this year? Or did you just mistype 10 instead of 12 for December of this year? I'm just trying to understand what you intended to write. Maybe you meant: The "Icarus" board without the mining software will be available a week ahead of the full release with the mining software.

Is that October 5^th of next year? Or May 10^th? Or something else?

This is fun to watch and compare with the historical record of the securities exchanges battling bucket shops.

About 100-something year ago the main weapon against bucket shops was to cut off their ticker: ticker literally meant telegraph.

So the bucket shop operators would bribe telegraph company linemen to surreptitiously tap the telegraph lines of some established brokerage.

I wonder what is the next salvo in this battle going to be?

I don't understand why anybody here is surprised by the prohibition of publishing any results of a benchmark. Nowadays it is pretty much standard operating procedure that publishing any benchmark results without vendor's agreement is a breach of license.

http://www.xilinx.com/ise/license/core_license_agreement.htm

http://www.xilinx.com/ise/license/license_agreement.htm

http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html

http://www.oracle.com/technetwork/licenses/solaris-studio-license-169628.html

I would be more surprised if anyone could show me a current licensing terms for an American product withouth the anti-bench-marking clause.