If the history is any guide openly blocking is least of the worry.

I have no data to compare Google legal eagles with Microsoft legal eagles, but Microsoft has about a decade more of the experience with their Passport and Live ID products. And before that Novell, Compuserve and Shiva, three other early pioneers of "single sign on service". Too bad that Netscape & AOL had purged all the old Compuserve forums. There were some nice stories to re-tell from some of the non-English language boards.

The problems are completely non-technical and non-cryptographic, they are all human factors and human resources issues.

And guys, remeber: the safest place to store the keys to your house is at the police precint. It saves the police the expense of getting a warrant when they will need to serve and protect you.

Anyone has any links to what Google does when they get a subpoena for the login credentials? The police must love OpenID.

Again, you are just showing how little you've understand of the problem of data integrity.

I've already posted this link couple of months ago.

http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx

Accountants don't use erasers yet they store their data in database? What gives? This article is a nice introduction to the concept of financial data integrity.

Core development team had choosen to take a detour and use LevelDB, a toy database written by Google folks to showcase their BigTable technology, but without the server farms, integrity guaranties, multitasking, multiprocessing, query optimization, statistics gathering, etc. Check out the posts of etotheipi, he'd just recently learned what the raw file storage does for the blockchain on a non- ECC RAM machine. There's going to be a lots of folks following them to the bit-flip-landia, unless they switch to Xeons and Opterons.

Who am I to tell them not to do that? They work for free and scratch their own itches. It isn't like they are answerable to the business development executives, aren't they?

Actually, the joke is on all those who use the bogus statistics to make a crucial architectural choice. The statistics promulgated by the core development team are a moral equivalent of: "we run a 'chkdsk /f' on a FAT and NTFS partitions. FAT was much faster, so lets use FAT for all our future storage needs. NTFS has so much unnecessary overhead."

This project has enough code cowbell already. What it needs is probably some new architecture. Thus far I think grau's bitsofproof is the best showcase of where Bitcoin can go with the "fast transactions folk".

This is true. But in the current state of the "Bitcoin engine" resembles a museum exponat. After 4 years of development there was no single deployment of Bitcoin in a proper transactional environment with two-phase commit (or something similar).

http://en.wikipedia.org/wiki/Transaction_processing

The blockchain and transaction information is still not stored in a database, but in a raw stdio/iostream file.

This is all because of the principle of "minimal intervention".

You can't successfully layer on top such a weak engine.

Yeah, the issues aren't really technical. They are the issues of mentality. The current prevailing mentality is "art project".

Bitcoin doesn't need to be attacked by anyone to increase in value. Why would a state attack something that amounts to an elaborate distributed art project? It is sufficient to manage the perception of scarcity. And this is true both for pro-state and anti-state crowds.

http://en.wikipedia.org/wiki/Conservation-restoration


If you have any doubts: check out posts from eg. cypherdoc. He not only invested in Bitcoin, but also bought the first issue of Bitcoin Magazine and stored it in a protective sleve. Maybe it will reach the price of the first issue of Superman comic book?

On the other hand promoting rapid and wide adoption is scary to both crowds too, but likewise for the opposite reasons.

It really isn't clear which strategy offers higher gain. And the answer depends on the time frame in the question.

It is simply not a good use of the available investment funds. Bitcoin has already significant costs sunk in. Expending a one-two man-years of a developer knowledgeable in finance, databases & middleware is just money better spent.
The coins are already half-way minted. Now the business question is:

a) do you want them tarnished (not necessarily with shit ) in a circulation?

b) do you want to wrap each one in a plastic display wrapper and hope they rise in value? I mean Satoshi Nakamoto is like Salvador Dali, he isn't minting anymore like Salvador Dali isn't signing any canvases, even blank.

Why call it silly? It is just a divergence of goals.

a) You belong to a group who wants Bitcoin to become a censorship-resistant Internet transaction media.

b) Core development team wants Bitcoin to become a value-preserving investment vehicle.

Group a) benefits from rapid evolution and good integration with the existing systems of electronic commerce.

Group b) benefits from paranoidal level of conservatism and avoidance of hard forks at all possible costs.

Is there a way to somehow unify those goals?

Maybe fund a stipend for grau and his bitsofproof? I think his code and his development style would be a good counter-balance to the obsesive conservatism of Gavin Andresen. Nobody in the core development team has any meaningful experience in development of transactional financial software.

This probably means that Luke-Jr had already reported you to the New York state crime autorities as somebody that runs a gambling racket. That's the "bet" in the original quote and it matches the modus operandi of Luke-Jr.

Erik & fireduck,

you should just offer a private betting addresses for your most demanding clientele. Basically have them login to your website and reserve a private set of betting addresses. Require a deposit, eg. 1BTC. From then on a private bet of 1.01BTC would mean than 0.01BTC is in the play and 1BTC is a conduit that you'll always return, both with the won bets and with the lost bets. A kind of a "refundable door charge." A sort of a thing that all decent casionos demand: evening attire. The casino will not strip the players from their clothes, even if they "lost their shirt" inside.

Good luck to everyone.

This is a sentence that mathematicians call "indeterminate form of the type zero times infinity". In other words: not a good sign of logical deduction.

Actually Gavin had advocated abandoning wallets swollen with coins that aren't currently economically significant.

By the time the exchange rate rises to the levels you are thinking of all the private keys will be forgotten, lost or abandoned.

The only hope is some sort of "admiralty rules" similar to "flotsam and jetsam" that will grant enterprising miners the salvage rights.

But that would be a hard fork, so...

I think of SatoshiDice as a proof by reductio-ad-absurdum that the Bitcoin needs to be continue to evolve to be really useable, lest it turns into a permanent worldwide register of dropped pennies.

Many developers associated with the core development team have lots of self-worth staked on the assumption that the Bitcoin is already perfect.

Your business is showing them that they were wrong. This is no longer a technical/scientific/business issue, it is now an issue of respect and/or self-respect.

I remember a comment from one of the professors in my university:

Q: Why are the panel discussions in this school are always turning so nasty?
A: Because the stakes are so low.

How beautifully naive. Or even naïve, with an umlaut.

Bitcoin thugs like Luke-Jr or gmaxwell are just not up to par in their thuggery skills, when compared to the government thugs.

Anyone can pretend that Bitcoin doesn't attract thugs, pump&dump artists and other problematic social element, but the "free market" is like the "spherical cow in a vacuum": it exists only as an idealized model.

Well, since the helveticoin user is tight lipped I had to search the STmicro press releases:


http://www.st.com/web/en/press/en/t3343


http://www.st.com/web/en/press/en/t3370

Pretty soon anyone in EU-landia could probably order this process through Europractice, the same way as bitfury did.

OK, I apparently misunderstood what it meant to be a "slave chip".
So, yaeh, if the "slave mode" actually works as advertised this may be a very competitive entry. The NRE costs are spread over multiple designs from the same European ASIC house. Just consider the entire Cortex-M3 a single large "defect" when estimating yield, because it only occupies a neglible portion of the chip area. I'm going to make an assumption that the designers were sane and they provided individual "clock enable" bits for the subregions of the hashing region of the chip so that the defect of a single hashing core doesn't disqualify a whole chip.

I always consider it a good sign when vendor gives a forthcoming and reasonable explanation for a misfeature or a drawback.

I wish good luck to everyone involved.

Edit: If you could answer one more question without an NDA: does the SoC have some analog circuitry to measure the temperature of the chip? Or at least there is some circuitry attached to some pin that will allow to build a temperature-to-leakage,leakage-to-time,time-to-digital termometer for the chip proper?

Thanks.

This is a very serious design mistake to mix up the hashing units and their controller on a single chip.

The primary problem is that anytime there is a internal miscompare detected it is impossible to distinguish the hasher failure from the controller failure. Therefore the whole design will have to be run at a fixed voltage and fixed frequency far away from the limits of the 28nm manufacturing process.

In addition to the above problem you'll suffer from the standard problems of manufacturing a chip containing complex circuitry like a SOC:

1) relatively low yield when compared to a repetitive chip like hashers,
2) you'll actually have to develop and pay for proper test of each manufactured chip unlike the hashers that are pretty much self-testing,

Finally, Cortex-M architecture doesn't run normal Linux because of the lack of the MMU that is included in Cortex-A chips that are popular tragets for Linux on ARM. It is possible to run some cut-down Linux on the MPU that is available in Cortex-M processors.

On the positive side Cortex-M is more resilient than Cortex-A in the presence of power-supply ripple and the extremes of the chip temperatures. The first circuitry to fail when overclocking/undervolting ARM is the MMU. So you'll be able to live somewhat closer to the edge of the process.

Another example of why decades of experience are no match for one year of clear thinking.

I doubt that the hasher portion of the chip has enough connectivity to the pins to be able to run it separately on a chip where Cortex-M3 failed the tests. But it may be possible to fill out all the available code memory of Cortex-M3 with multiple implementations of a trivial hasher driver that uses various instruction sequences. When the CPU portion of the chip fails it may still execute properly only some of the instructions or the code where every other instruction is a NOP.

The last time I had information about per-instruction failure rates was for Intel 80386 chips. An example of permanent manufacturing failure: certain 32-bit multiplications failed. If you only used 16-bit multiply everything was working fine. An example of temporary failure due to overclocking/undervolting: POP SS failed. But if you had a code than never modified the stack segment register it would work fine, so the CPU was useable if the whole code&data fit within 64kB and the segment registers were never modified.

As a software developer you may be able to develop a similar set of rules and workarounds for Cortex-M. As a partner just design a large PCB where single Cortex-A SOC running proper Linux controls the multitude of those Cortex-M & hasher chips.

Please update the poll to include one more option:

x) redefine "block" to mean only header, Merkle tree & coninbase transaction. All normal transactions need to be propagated before the block in which they are included.

This proposal has been floating around at least since the Microsoft's "red balloons" paper. Currently "block" is pretty much an artefact of the weak architecture of the original implementation. The various "UTXO" proposals are in effect proposing the same change, just a different implementation of the transaction storage.

Thanks.

Edit1: Changed "fix" to "update". I forgot that in English "fix" could mean "conspire to preselect the winner".

Edit2: This "block size" discussion should really decouple the "bandwidth & time to verify" from the "storage size" discussion. They aren't really coupled, the coupling is just an artefact of implementation.

Actually the above is a common misconception. It is only true in a very generic cases. In the cases like a Bitcoin client we would have essentially a single application using a single database schema.

With such a combination it is possible to write a trivial custom database driver. It could use regexp to match the handfull of the necessary SQL statements like "SELECT * FROM values WHERE key=?" and return "not implemented" error in all other cases.

I don't have a firm opinion whether this is a suitable approach for Armory. But I'm positive that it could be a great win for the single-user-in-a-single-process database engines like LevelDB. It may be a simplest way to allow the database to be shared between multiple processes and multiple users as well as a true decoupling of the data storage from the user interface.

I think you are getting close to understanding the reverse-delta concept.
It is a postfix notation where forward-delta is an prefix notation.

Currently the "block" message consist of header, Merkle tree & array of transactions. Most of the bytes are used for "array of transactions" are aready a duplicates of what had been seen in the "tx" messages.

When doing reverse-delta the "array of transactions" is not send in the block, only the header and the Merkle tree. The transactions had been already sent in the "tx" messages.

I believe Microsoft Research folks have already discussed this change in their "red balloon" papers:

https://bitcointalk.org/index.php?topic=51712.0
https://bitcointalk.org/index.php?topic=64738.0

as one of the ways to remove the incentives to hide the transactions from the rest of the network.

In other words: You want to get your mined block accepted really fast? Send all the transactions ahead.

Or maybe another way: the reverse-delta concept affects both the network protocol and the transaction storage. They don't have to be taken both at the same time.

Those arguments about block size are a classic example of strawman argument from the "old money" & "old code" side. The forward-difference state maintenance was good for the proof-of-concept. But in practice nearly everyone does reverse-differencing.

https://bitcointalk.org/index.php?topic=87763.msg965877#msg965877

It is really old and well researched problem and almost all practical solutions use reverse-delta or some variant involving reverse-differencing.

I fully understand that given current situation there are no human (and other) resources available to move the network protocol and the code base forward.

Just don't say that there's no way forward.

As much as you hate my Bitcoin Airlines story it is a decent analogy: adding "fuel fees" to the "seat ticket transaction price" isn't going to make the Airline more popular and safer.