I, on the other hand, would put this to a combination of "figure of speech" and "language difference".

https://en.wiktionary.org/wiki/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C

One way of translating English "director" to Russian would be "руководитель", which in turn translated literally back to English would mean "the one that leads by the hand". In many Slavic languages the equivalents of English "by hand" and "manually" have much wider, figurative use. For example the title of this old thread https://bitcointalk.org/index.php?topic=49971.0 "Algorithmically placed FPGA miner" could be translated to Russian and back to English as "Hand tailored (or Hand cut) FPGA miner". Somewhat more humorously, some not-that-well translated software documentation uses the above Russian word for the "device driver".

Even native English speaker constantly communicating with bilingual or multilingual people will subconsciously pick up their speech patterns and figures. My favorite example is: the equivalent of English "all thumbs" in several other European languages is "two left hands". Both of those phrases aren't meant to be literal, they are just figures of speech describing a person lacking in manual dexterity.

So my guess is that the PR blurb-writer picked up this hyperbole from the native speakers of Slavic languages who only know English as their 2nd language.

Edit: I've forgotten to add that the in my favorite example to cognitive adaptation is not only linguistic but also involves the associated hand gestures. The "all thumbs" is gestured by curling 8 non-thumb fingers at the knuckles to match the length of the thumbs. The "two left hands" is gestured with showing both hands with thumbs pointing to the left.

Man, I'm sorry to have stepped on your toe. You really seem to have proper technical outlook on the issue. But you seriously lack in the "street smarts" department. The salespeople must love you. You just telegraphed your insecurity in the first two sentences.

In case you didn't read my first post: I haven't questioned anything technical in your observations. You just missed the proverbial forest for the trees. There are multiple areas in which the Core Bitcoin client has "possibly great potential to improve". But very few people care, the issue is about who has the control of the direction of the project. The existing bugs and deficiencies are carefully maintained through the code pulls to preserve the future opportunities for soft forks.

Couple of years ago I had to quickly help a friend with reviving his ailing Windows machine. Every hour counted, we decided to buy the required discrete graphic card in the nearby mall's store catering to computer gamers.  Unfortunately we hit it during really busy time, the checkout line was over 1 hour. During that time I learned that many average teenage boys have good handle on the politics of various 3D graphics APIs (e.g. Microsoft DirectX vs. OpenGL) and various quirks of how they affect games releases, prices, platform availability, etc. They were quite "street smart" despite shopping in the typical mall under watchful eyes of their parents.

Edit: Since your background is in high performance memory based database systems, here's the idea: open a new thread about replacing mempool with a general memory-based database. Stick to the technical benefits. And then watch the comments flow about how not using a sensible database for mempool is crucial about maintaining the security of Bitcoin. Maybe that will open your eyes to what is really going on here.
 

Man, you seem rather naïve. The non-use of serious database technology and deep enmeshing of educational-toy database engine (LevelDB) into the Core client source code are the key ways maintaining control of the project within the small core team.

It is kind of article of faith and a way of keeping the anarchist spirit of the project: if you want to use a serious DBMS you are a corporatist shill and a bankster bent on taking control of the project from the people!

Also, don't even think of abstracting the storage layers used by Bitcoin Core! Look at what happened to etotheipi and his company when he decided to switch.

Edit: The Core Team has actually achieved the holy grail of billing-by-the-hour software consultants: they included their own fork of LevelDB into the Core and maintain it separately from the Google's one.

If you don't mind translating from British English to the International English:
What does "no calls" mean in the UK? Does this mean that:
1) they won't negotiate the requirement of analog phone line (called POTS elsewhere);
2) that the analog phone line will not allow incoming and outgoing calls made with analog phone and will be only used to provision VDSL2 signal to the box at your home.

In other words: is your analog telephone still connected to the copper wires coming to your home (possibly through a DSL splitter/filter) or did they force you to plug in your analog phone into a dedicated socket in the VDSL2 modem box?

Or maybe in still different way: if the electricity fails in your home or VDSL box is inoperable, would you still be able to make calls (e.g. 112 emergency) with our analog phone powered from the battery in the central phone switching office?

Thanks in advance.

No, really no. The similarities are superficial only.

To clarify the difference I'm saying that this project/idea is scoped to be fully implemented in approximately 1MB of executable code. Somewhat limited implementation could probably be made on the historical CPUs like Intel 8086 or Hitachi HD64180. Fully featured implementation will for sure fit in a CPU with 16MB of address space like Intel 80286 or Zilog eZ80 (the new one, not the historical Z80) or the modern compatibles to the historical PDP-11/LSI-11. Basically any CPU supporting multiple banked/segmented 64kB address spaces is the satisfactory target.

The segmented/banked 16-bit-ness is not a requirement. The implementation could as well use the modern flat 32-bit or 64-bit addressing. However it is my experience that explicitly segmented 16-bit address spaces are a great aid in enforcing security and safety of the code. They are also aids in mechanical proving of the code correctness (even if only partial proofs).

I'm not actually advocating the use of those historical CPUs running with clocks in the single MHz range. I'm thinking of drop-in cores to be synthesized using modern FPGA or ASIC processes with the modern clock rate of high hundreds of MHz . The physical package of such cryptographic kernel device would be similar to the (nano-)SIM card or (micro-)SD card.

The supporting blockchain data is a different story. It would have to be either local storage in the present terabyte ranges or a networked access to the remote storage at single megabits per second speeds.

Edit: Anyway, I've read the tauchain whitepaper as well as all the 18 pages of the tauchain thread with interest. Thank you very much.

Yup. This is a trivial result from the classical papers from 1955 and 1956.

https://en.wikipedia.org/wiki/Mealy_machine
https://en.wikipedia.org/wiki/Moore_machine

I just had to consult the Wikipedia to verify that John Von Neumann published his paper earlier, in 1945.

Some schools must be really bad if in the 21^th century they don't teach the science from the middle of 20^th century.
 

Maybe somebody at Bitmaintech read the documentation to their synthesis tool all the way to the end (and with understanding   ?)

The problem with SHA-256 is that it causes very slow convergence in the automatic synthesis tools. Because there are no external timing constraints (see https://en.wikipedia.org/wiki/Timing_closure ) the optimization algorithm has no real direction to seek and starts very slowly searching the humongous design space of filling out the chip with hashing engines. Adding some artificial constraints greatly improves the speed of convergence by avoiding unnecessarily spending time on obviously unproductive (to a human) design variants.

For example see my avatar: it is a floorplan of completely unrestrained implementation of a single fully unrolled SHA256D pipeline. The synthesis algorithm self-placed both input and output pins to the I/O bank at the center of the chip and then routed around that bank. Yellow is the first SHA-256, green is the second SHA-256.

Compare it with a hand-restrained design by eldentyrell where he intelligently squeezed 1.5 times more hashing into a smaller chip: https://bitcointalk.org/index.php?topic=49971.0

Yes, the meaning of word "shill" has changed, the dictionaries don't keep up with the evolution of the English language. Shill has mostly lost its negative connotation and isn't going to be an effective insult anymore.

By the way, it wasn't "authorities" who demanded disclosure, the "investors" demanded it.

At the turn of century "shill" may have still been a negative word, e.g. Sony officially called their shills "street marketing teams" or "street marketing representatives". "Shill" is nowadays just another occupation, like a "salesman". Except that nowadays "salesman" sort-of became a nasty word, "salesmen" and "saleswomen" are now "account executives".

This is a controversy only for the schoolmarms amongst the physicists. The saner ones have no problems with the world "implosion" because the well-controlled demolition aims to contain the debris within the narrowest possible perimeter.

Anyway, I don't want this to became a language discussion. I much rather stick to the legal definitions of the word "shill", thus my reference to NGCB instead of a dictionary. My guess is that people who continue to think that "shill" is kind of an insult are English monolinguals. But this website is aiming at a global audience.

Jeez, dude, read all the way to the end, would ya?


Do I need to enlarge the font in the last sentence? Or maybe change color?

The dictionary definition is out of date with respect to the "without disclosing close relationship" clause.
The modern legally standing definition of shill is something like:
I quote NGCB because their definitions and rulings are considered authoritative even far away from Nevada, practically everywhere with common law legal system.

Shilling (both openly and surreptitiously) is widely used in the various branches of the entertainment industry. Not only gaming (also called gambling) but also e.g. sales of equipment to musicians or filmmakers.

Again the issue with modern shilling is that one can do shilling in the open: with the disclosure of close relationship.

Could anyone kindly quote this entire reply for posterity? Thanks.

Now that is one of the weirdest claims I read on this site.

You seem to be unaware of the existence of the whole areas of the https://en.wikipedia.org/wiki/Automata_theory that study things different than the prevailing https://en.wikipedia.org/wiki/Von_Neumann_architecture .

Are there any reputable schools granting Computer Science degrees without requiring the student to understand the fundamentals of digital logic design (e.g. a flip-flop)?

Whole message quoted again for posterity:

Register yourself at the Synopsys website. There's a wealth of information available there, and if you actually physically participate in any of their sales events you will be sure to meet the right people who could work with you.

The information below is out of date, I just opened the e-mail from Synopsys too late to be of immediate help:


Edit: corrected the year error that was in the blurb. They sent me an invitation on 2016-01-11 for the webinar supposedly held at 2015-01-13, but really held in 2016. I'm not that tardy with opening e-mails 

Thanks for the thoughtful reply, I'm glad to be able to read your words when you really apply yourself instead of posting dismissive single sentences.

The "high cost" of p2pool as it is right now is because it applies to full, high hash power into the lower-level blockchain with fast blocks (less than minute).

When p2p-pool idea would be applied to the propagation tracing only a fraction of hash power would be applied to the fast-chain. The majority of hash power would still go to the slow, decaminute normal Bitcoin chain.

When p2pool would be used just as a proof-of-propagation the required fraction of total hash power would be rather low, probably around single percent. Therefore the cost of orphans would also be insignificant in comparison to the total hash power. I'm not going to repeat the whole analysis done in Microsoft Research's "Red Balloons" paper. Interested readers could easily find it themselves.

The general idea still stands. Why it isn't getting much interest in Bitcoin milieu is a different story, rooted in political-science not in computer-science.

I only agree to the "control" part. The "greed" part is a flip side of the same coin that has "stupidity" on the other face. Lots of folks went into Bitcoin hooked on various populist propaganda slogans and without real understanding of the underlying technology.

p2pool doesn't enforce the political goal of system distribution. It only allows it at a cost of a slight overhead. So by itself p2pool (and similar extensions) would do nothing to prevent the dominance of large farms.

The goal of "evolving without intervention" is a completely different story. I still have my proposal (BIP 2112) from many years ago in my signature. But the current prevailing climate is that people prefer to fight over branding (My coin is the Bitcoin, yours is an altcoin!) instead of working for the common goal.

Dude, you are so wrapped in your old polemics and boxed-in thinking, that it beggars belief.

Of course, it will not be straight as-it-is p2pool integration with the main protocol. p2pool currently is focused on tracking only "shares" of work towards the upper layer block. But it has show itself resistant to Sybil attacks and shown that the global convergence to common goal can be achieved in less than 10 minutes of the plain Bitcoin network.

The concept of p2pool can easily be extended to keep tracking not only shares towards common block hash target but also Merkle sub-trees pf transactions contributing to the global common Merkle tree in the common block header.

The new added benefit will outweight the known drawback of slightly increased losses due to stale shares and more frequent orphaning at the lower-layer block level.

So the knowledge and technology to maintain globally converging "mempool" or list of pending transactions is already there. There is simply no will to implement it.

P2P-pool works and is Sybil-resistant. Its faster and easier blocks serve as a very good approximation of global convergence to a single second-level slower and harder block.

The obstacles are purely non-technical. Many people find it profitable not to look for solutions. That's pretty much most of the story. Edit: the rest of the story is more like religious/theological argumentation in https://en.wikipedia.org/wiki/Eschatology .

It would be relatively easy to approximate the existence of the global pending transaction list. I hate the term "mempool" because it is just an example of terminal in-box-thinking. "The mempool" is just a database stored in a really primitive way in memory, instead of some more advanced way like storing them in a https://en.wikipedia.org/wiki/In-memory_database .

The implementation would require folding the p2p-pool mining protocol into the main protocol where it would serve as a sort of proof-of-transmission that is resistant to the Sybil attacks. This has been discussed many times before.

Anyway, that isn't going to be implemented in Bitcoin for political reasons, not for any technical/scientific/economic reasons.

This thread is only of historical relevance. It pertains to the old version that used BerkelyDB for everything. Current version uses a mixture of BerkeleyDB and LevelDB, so it doesn't apply.

I think that the science that says "no known solution" is still young in the timeline scale of humanity. As they say: necessity is a mother of invention. I'm willing to wait for either a better solutions or a better proof of incompleteness.

OK, now I understand that you have an oddball sense of humor.

The "full node" is traditionally defined as a node that:

1) knows the entire blockchain history
2) propagates transactions and blocks after verification

The "pro-pools" legacy meaning included one more function:

3) mines blocks

Bitcoin started in the situation where mined coins paid for all 3 things:
3) electricity spent on PoW
2) network bandwidth
1) block storage

Now that node specialization is progressing I think the first two functions will get unbundled too. I thus don't consider "full node" a very important concept. Perhaps it would be better to split it into 2 or 3 terms:
i) real-time propagating node
ii) UTxO query-service node
iii) archival query-service node
depending on how far we would want to go into unbundling.

The problem with unbundling is that there's nobody paying the fourth cost:

0) research and development

Therefore after mining got unbundled the developers were left to funding themselves by extortion,  scams, rip-offs, vulture/venture capital, preying on the naïve and other miscellaneous funding sources.