OK, so somebody posted then quickly deleted a follow up to my messages above. I only took a glance before I was interrupted, but the main take-away was that indeed I should clarify what I meant.

So lets roll back to the original Satoshi's transaction design.

There are basically 3 main goals that the transaction format has to fulfill:

1) reference source and destination of funds, as well as amounts
2) cryptographically sign the source references to prove that one has control over them
3) detect (and possibly correct) errors in the transmitted transaction: both intentional (tampering) and unintentional (channel errors)

The original Satoshi's design used single SHA256 hash to cover all tree goals. It was a neat idea to kill 3 birds with one stone. But then it turned out that only 2 birds get killed, the center one is only getting injured. At it has about two lives: low-S and high-S.

So then we start trying to address those 3 main goals using a separate fields in the new transaction format. I'm not really prepared to discuss all the possibilities.

Lets just discuss a possible encoding for single UTxO reference. The current design is an ordered pair of (256 bit transaction id,short integer index of the outputs within that transaction). Lets just also assume that for some reason it becomes extremely important to shorten that reference (e.g. transferring transactions with a QR code or some other ultra-low-power-and-bandwidth radio technology).

It may turn out that the better globally unique encoding is an ordered pair (short integer block number in the blockchain, short integer index to the preorder traversal of the Merkle tree of transactions and their outputs). It may be acceptable to be able to refer only to the confirmed transactions in this format.

I'm not trying to advocate the change of the current UTxO reference format. All I'm trying to convey is that there are various ways to achieve the required goals, with various trade-off in their implementation.

Both the original Satoshi's design as well as the current SegWit design suffer from "just-in-time design" syndrome. The choices were made quickly without properly discussing and comparing the alternates. The presumed target environment is only modern high-power high-speed high-temperature 32-bit and 64-bit processors and high bandwidth communication channels.

Around the turn of the century there was a cryptographic protocol called https://en.wikipedia.org/wiki/Secure_Electronic_Transaction . It was deservedly an unmitigated failure. But they did thing right in their design. The original "Theory of operations" SET document did a thorough analysis of design variants:

1) exact bit counts of various representations and encodings
2) estimated clock counts of the operations on the then-current mainstream 32-bit CPUs
3) estimated clock counts of the operations on the then-current 8-bit micro CPUs like GSM SIM cards
4) estimated line and byte counts of the implementation source and object codes
5) range of achievable gains possible by implementing special-purpose hardware cryptographic instructions with various target gate counts.

Again, I'm definitely not advocating anything like SET and its dual signatures. I'm just suggesting spending more time on balancing various trade-off and possible goal of the completed application.

The "cleaner" part is true only to subset of people: those that were actually considering the original Satoshi's design as "ideal" or "perfect".

I personally think that the original design where "transaction hash" is both a "transaction identifier" and "transaction checksum" as a sort of a "neat hack".

Edit:
The requirement for segregation is really only for "logical" segregation, not "physical" segregation.

My opinion is that the main point of the contention is that more programmers agree that "logical" (or algebraic) segregation is OK. Only much smaller subset of programmers agree that "physical" segregation (being far away in the serialized bytestream on the wire or on the disk) is the correct way to implement the algebraic segregation.

Edit2:

In addition to the above there is an issue of what is the optimal length of "transaction id" and "witness id". Transaction identifiers have to be globally unique, whereas "witness identifiers" only have to be unique within the block that they refer to. So the optimal length of the witness id could be much lower than 256.

I'm still unsure why we started talking about fees in this thread. The fees enter the consensus validity rules only when verifying that they aren't negative. The fees have to be positive or zero. The value of fees is only used when priority-sorting the already verified transactions.

Also, I don't believe in the existence of non-fixable bugs in the old rules that "fork (rule change) was executed to fix a bug or prevent an attack, the miners cannot continue to use the old rules for transactions that have the old version tag".

Edit: Getting back to the original argument:
Perhaps the DOS/Windows argument wasn't the best. The better, but less well known, example would be mainframe disk device drivers. They easily cover old-style devices with interfaces designed in late 1960. The hardware implementations are "frozen" in the sense that nobody changes the relevant hardware logic anymore. It is just a small sub-area in the modern VLSI chips that implements exactly the same logic as the old TTL-style disk interface controller.

Nobody designs or writes an interface that is sprinkled with conditional logic to handle the old protocols (if () then {} else {}). There's one time inquiry to verify the protocol version used and then all operations are handled through indirection (e.g. (*handle_read[versn])(...).

Same idea could be applied to Bitcoin if the version field would be appropriately changed both in blocks and transactions.

I don't buy the argument about "frustrating that measure". It is very easy to verify that the "old style" transactions use only "old coins", the coins that were confirmed no later than the effective time of the new transaction format.

Theoretically someone could try to launch the attack using only the "old coins", pretending to have a pre-signed transaction with some rather large n-lock-time. I think that type of attack would be self-extinguishing, it could be launched only once for each "old" UTxO entry.

This cannot be right. The Satoshi Bitcoin client always stored blockchain as the plain flat files. The database engines were used only for indexing into those files. The recent LevelDB-based backend worsened the situation by explicitly storing (also in plain files) the some precomputed data to undo the transaction confirmations in case of a reorganization.

The proper way to modularize the storage layers is to completely encapsulate all data and functions to access blockchain, without the crossing the abstraction layers inside the upper-level code.

I stress that "storage layers" need to be plural. The mempool is also a storage layer and also needs to be properly abstracted. In a proper, modular implementation the migration of transactions between those storage layers (for unconfirmed and confirmed transactions) will ideally require setting one field in the transaction attributes, e.g. bool confirmed;.

I wonder if that was a typo or a subliminal way to suggest that we sell.   

Good. For those unfamiliar with that area of science here are good links to start their research:

https://en.wikipedia.org/wiki/High-level_synthesis
https://en.wikipedia.org/wiki/High-level_verification

From the past experience talking with you I think you are just pretending to be a dumbass. But it is also possible that you don't understand the difference between the old stopping problem and the automated logical equivalency verification like the one used by ARM to verify the implementations of their namesake architectures.

Every CAD/EDA tool vendor has tools to do automated verification and automated test vector generation. The obvious problems are:

1) those tools are closed source
2) those tools are very expensive
3) the input languages are hardware oriented: Verilog & VHDL mostly, with only recent additions of SystemC or similar high-level-synthesis tools.

That isn't even anything new like zk-SNARKs. Those tools were in use and on the market for more than 10 years. I had used some early prototypes of those tools (based on LISP) in school back in 20th century.

Of course. Machine verification. It could be even a subset of C++ like SystemC. But the proper definition of consensus-critical portion should be machine-verifiable.

I'm pretty sure that at least gmaxwell understands the importance of that. He's an advocate of zk-SNARKs and those have a synthesis of logic circuit equivalent to the given program as one of the intermediate steps.

The zk-SNARK people in Israel designed and implemented some subset of C (not C++) to facilitate logic synthesis. It is a key step to machine verification of the code.

Apparently for the original Bitfury chips the numerical value of "suckage" was such that it was still worthwhile to buy/sell them.

IIRC the even the original Bitfury chip has some sort of bit vector that enabled/disabled individual hashing cores. I don't think that they would've removed it from their newest design. It is fairly simple design-wise to take care of clock-disabling and powering-off "cores shot".

I think many people in this thread are in their mind designing miner according to some ideal "specification-in-the-sky" or "spec-sheet-of-their-dreams". I'm all for doing idle speculation as a mind exercise when there's not much else to do. But if somebody wants to do non-idle stuff then it is better to learn some basics of engineering instead of incessantly placing bets on various pies-in-the-sky.

 

By now I probably should have my standard debunking of the "low yield" argument assigned to a single-key shortcut.
Bitcoin mining chips are too repetitive to apply the industry standard measures of yield.

The big names mentioned like Intel,Apple,etc. order extremely complex digital chips with very little redundancy. In particular the industry standard testing framework (JTAG) requires that all (or nearly all) flip-flops on the whole chip are threaded onto a single JTAG-chain for testing. Any break or short in JTAG-chain will make chip faulty even if the all non-testing logic is correct.

On the other hand Bitcoin mining chip consist of ridiculous amount of redundancy and SHA256D is self testing. therefore the standard JTAG chain would be a complete waste of space.

In case of Bitcoin mining chip a "50% yield" would mean than on the average chip about half of the hashing engines in the sea-of-hashers are working correctly. Such chips would be still commercially viable and sellable.

In addition to the above Bitcoin mining chip is nearly 100% self-love, it doesn't have to interface or be compatible with any external standard like DRAM or WiFi. Nearly all functional and timing violation could be worked-around at the driver level.

To refresh the history: the original Bitfury chip had yield of 0%: it was supposed to produce 5GH/s but only achieved 2-3GH/s. Additionally there was some scramble/permutation in the output logic that required inverse permutation in the mining software. Yet those chips sold quite well. Not only they sold, they also made money for buyers.

In summary: if you want to make non-absurdist conclusions about Bitcoin mining chips you'll need to use the yield measures used in the analog & mixed-signal fields, not the ones used in the digital logic field.

Multithreading.

Deep understanding of Bitcoin? It was disproved few pages ago by knightdk. JorgeStolfi clearly has no elementary comprehension of the source code of Bitcoin.

Yet he continues to post trivialities like:
which was already stated in the original Satoshi's whitepaper. This isn't deep. This is as shallow as it gets.

CIYAM tends to think that JorgeStolfi is some sort of paid disinformation operative. From my personal experiences with peer-review I would venture to guess that he may be heavily medicated or have some sort of amnesia. Such people tend to have good recall of the recent facts and recently acquired knowledge but start to have problems with recall and application of facts and knowledge acquired years ago.

OK, now you've shifted your position to open crackpottery.

The original implementation certainly had non-mining relay nodes. In the original implementation mining (then CPU-only) was explicitly optional. The shift between the original and current is just that nowadays the probability that the randomly connected relay node also does mining is much lower.

Non-mining relay nodes have several useful purposes: probably the most important one is as a first line of defense against denial of service attacks. Especially if such nodes are run in the cloud service provider who charges $0/GB for incoming traffic (like Amazon EC2): it nearly completely defangs the most common DDoS via UDP flood.

I have to observe that for somebody with an actual scientific degree you are making questionable statements too fast and too often.

You started writing really weird conflated stuff. What do fees have to do with transaction syntax?

The version field should be used to clearly describe syntax rules governing the transaction format.

The amount of fees doesn't change the syntax, so doesn't require change of the version.

The existing client already has "misbehavior" score to disconnect itself from other peers that try to abuse it in various ways. There's no point to invent new mechanisms to do it. All that could be possibly required is to tune the specific values for various misbehavior demerits.

Your argument is technically specious. Transactions in Bitcoin have 4 byte version field, that gives us potential for billions of rule-sets to apply to the old transactions. The correct question to ask: why this wasn't and isn't changed as the rules gets changed?

I disagree on the "tough" part. In my opinion this is less difficult than DOSbox/Wine on Linux or DOS subsystem in Windows 32 (and Itanium editions of Windows 64). It is more of the problem how much energy to spend on scoping the required area of backward compatibility and preparing/verifying test cases.

The initial step is already done in form of libconsensus. It is a matter of slightly broadening the libconsensus' interface to allow for full processing of compatibility-mode transactions off the wire and old-style blocks out of the disk archive.

Then it is just a matter of keeping track of the versions of libconsensus.

To my nose this whole "segregated witness as a soft fork" has a strong whiff of the "This program cannot be run in DOS mode" from Redmond, WA. Initially there were paeans written about how great it is that one could start Aldus Pagemaker both by typing PAGEMKR on the C> prompt (to start Windows) and by clicking PageMaker icon in the Program Manager (if you already had Windows started). Only years later the designers admitted this to be one of the worst choices in the history of backward compatibility.

I don't know. What I do know is that fraudster and gangsters (more generally common criminals) have exceptional sensitivity to being given "no respect" (cue Marlon Brando in The Godfather). Of course, correlation is not causation. But see how DeathAndTaxes reacted to the mention of money orders in 2012. I think that even he didn't know at that time what scam he's going to pull of years later.

https://bitcointalk.org/index.php?topic=93655.msg1036760#msg1036760

Your reaction to the mention of high-school-level science curriculum is very similar.

Again, time will show.

Take mountain climbing as a hobby. Your main adversary will be then impersonal gravity. But you'll learn to deal with reality and how to overcome obstacles. Or you'll get yourself killed.

I'm actually proud of getting called troll by now know fraudsters like DeathAndTaxes or shtylman. On you the question is still open: are you leaning more towards harmless crackpottery or towards willful fraud? We'll see.

This is public forum. I make post useful to the global audience of the readers, even if they aren't useful to you or any particular poster of any thread.

Your math error is called: GIGO https://en.wikipedia.org/wiki/Garbage_in%2C_garbage_out .

The mistake you are making is common enough that there's lots of educational texts regarding the "correlation vs. causation" issue. When I was in school profs used to refer to an excellent joke paper written by some Scandinavian scientists about presence of storks and childbirth rates in Scandinavia. I'm not sure if it was ever translated to English.

Edit: More seriously: many law schools offer "personal development" classes on how to deal with adversity in a public courtroom. Apparently it is a common problem for even excellent students that were home schooled or went to religious schools.