@AlexGR, everything in Ethereum is deterministic. There are no operations that have different results on different nodes. At least if everything works properly. If not then it can fork the chain.

Aha, that's closer to the answer I was hoping for. Thanks.

Ok, so is it censoring code that it doesn't like or something?

Let's say randomizing numbers is out of the question.

Now let's do something else. I'm adding a constant number (not random), let's say the number 42, for 1 entire second. Everything is given / predetermined: a) The number to add (42) and b) how long I want it to perform what I want (1000 msecs). The result though is different because one pc will have made 500 million additions, another will have made 10 billion additions, depending their cpu power.

Can I fork the network now?

On the same trail of thought, pursuing disagreements in the computations of the network to fork it:

tromp's reply didn't really answer the question. Basic floating point operations are supposed to be deterministic anyway. The question was whether a hardware bug causing incorrect/different results (in operations that are used in Ethereum) could fork the network and the answer is yes.

Of course this could happen in another coin too. A hardware bug, in theory, could cause a valid signature to appear invalid on some hardware and therefore cause the majority chain to appear invalid, which would then result in a persistent fork.

I found it extremely hard to believe that floating point can't be supported. Floating point is required in a lot of financial transactions.

Anyway this should be very interesting in terms of cpu microcode updates and related errata (which is a blackbox situation), plus possible government involvement to orchestrate possible trigger scenarios / kill-switches as an attack vector...

The only way to mitigate this would probably be to conduct software emulated math functions, at a much slower pace. But it would need a run option like -softmath or something.

Crypto currency innovations can't be stopped at any time by any means. If LN is the hot task for this year, something new will be there in the next year. LIkewise, ETH may be overrided by something better than that of eth's innovations and promises.

Still that ETH teenage developer just schooled the entire Monero developing team "website designers/gambling sites/#waiting for my GUI". While you guys including TPTB_need_war who is also dreaming about creating he's coin that should as he indicates for like two years now that will solve every other coins problem yea big "LOL" crying so much in a bitcoin forum that filled with shills like you/ haters like you/ & just pure jealousy of people success. It is as if you wish that everyone who invested in any coin that you don't support is to just lose it ALL so your dirty souls can smile once in their life for once.

No wonder you guys are barely mentioned in a crytpo dedicated website because you are full of hot air.

Still that ETH teenage developer just schooled the entire Monero developing team "website designers/gambling sites/#waiting for my GUI". While you guys including TPTB_need_war who is also dreaming about creating he's coin that should as he indicates for like two years now that will solve every other coins problem yea big "LOL" crying so much in a bitcoin forum that filled with shills like you/ haters like you/ & just pure jealousy of people success. It is as if you wish that everyone who invested in any coin that you don't support is to just lose it ALL so your dirty souls can smile once in their life for once.

No wonder you guys are barely mentioned in a crytpo dedicated website because you are full of hot air.

(another plausible answer is that LN works perhaps only with a fully centralized coin, so perhaps that is where Blockstream has been paid $75 million by the banksters to lead us to, but I am hoping that is not the case)

(or alternatively, the banksters have paid Blockstream to clusterfuck Bitcoin, whether Blockstream realizes it or not)

Control freaks inherited from Mozilla such as the HTML5's Ian Hickson prototype now in control of Bitcoin too. I've been butting heads with these control freaks for more than a decade.

They conflated the framing and data layer for Websockets for example even after I explained that to them.

They'd rather do it wrong than to not be the one in control of the doing.

Doing so would also increase the overhead for the format by 20% or so. As mentioned, accurate indexes are not small-- and many things compromise by just not providing accurate indexes; which then leaves applications linearly scanning or not permitting sample accurate seeking.

I assume the 20% estimate is only for when the optional index is present. So it is presumed someone would use an index only when that 20% was justified by their use case. Again I argue you should not remove degrees-of-freedom and hinder the optimization of use cases which you did not envision because no group or person is omniscient.

And how is not having the index any worse than not allowing an index. I fail to see the logic. Seems you are arguing that the receiving end will expect indexes and not be prepared for the case where indexes are not present. But that is a bug in the receiving end's software then. And in that case, there is no assurance that software would have done the index-less seeking more efficiently for the status quo of not allowing an index. None of this makes sense to me.

Also I don't understand how you calculate 20% increase in file size for adding an index. For example, lets take an average 180 second song consuming roughly 5MB for VBR encoding. Let's assume my users are satisfied with seeking in 1 second increments, so that means means I need at most 180 of 22-bit indices, so that is only 495 bytes which is only a 0.01% increase! On top of that I could even compress those 22-bit indices into relative offsets if I want to shrink it by roughly 75% to 0.0025%.

Note that doesn't mean these guys aren't smart and expert in some areas.

In Blockstream's case, taking into account SideChains and LN, I am thinking they follow the Rude Goldberg principle of design. In Ian's case, I think it is "simplicity is beauty at any costs" or something like that.

Note Brendan Eich has been doing well with EMCAScript (Javascript) apparently. I've had no experience with him so it is not a blanket accusation towards Mozilla, but rather apparently some of the people who have gravitated to open source standards work apparently due to the political control.

He also didn't say that floating point can't be supported only that it isn't supported natively. A floating point number is actually just two integers packed together into a single data element. That can still be done when needed on top of integers.

I've read some of the suggestions in that link but it doesn't make sense to me how it can replace a lot of use cases (except, as I have suspected, that catastrophic failures can occur by the use of fp). Granted I'm not a programmer, I'm currently asking for ...lessons here

Let's say I lend someone 0.15$ and have 0.3% daily interest.

Ok, let's pretend dollars aren't dollars, but they are cents (thus 15 = integer). Even if the interest was a floating point setting (I guess there is an equivalent mechanism to make decimal stuff like interest into integers - after all the cpus do that stuff all day long at the binary level), and we did the math, then 15 cents + 0.3% = still 15 cents at the end of the day. And in the end of the next day. And the end of the next day as well.

So I've lent my 15 cents into a money lending platform, and instead of getting compound interest, I'm stuck at 15-15-15-15 every day... So, after a year I should have 44.7 cents (tripling my money) but now I have just 15 cents - so I'm robbed. It seems this is pretty bad and very close to a rounding error that is always against me - kind of.

I've read some of the suggestions in that link but it doesn't make sense to me how it can replace a lot of use cases (except, as I have suspected, that catastrophic failures can occur by the use of fp). Granted I'm not a programmer, I'm currently asking for ...lessons here

Let's say I lend someone 0.15$ and have 0.3% daily interest.

Ok, let's pretend dollars aren't dollars, but they are cents (thus 15 = integer). Even if the interest was a floating point setting (I guess there is an equivalent mechanism to make decimal stuff like interest into integers - after all the cpus do that stuff all day long at the binary level), and we did the math, then 15 cents + 0.3% = still 15 cents at the end of the day. And in the end of the next day. And the end of the next day as well.

So I've lent my 15 cents into a money lending platform, and instead of getting compound interest, I'm stuck at 15-15-15-15 every day... So, after a year I should have 44.7 cents (tripling my money) but now I have just 15 cents - so I'm robbed. It seems this is pretty bad and very close to a rounding error that is always against me - kind of.

If you are running a lending platform that calculates daily interest and deals with loan amounts in cents, then you can easily make your minimum unit be thousands of cents or smaller.

Some of the bitcoin exchanges, for example, use sub-satoshi units (< 10-8) internally and only convert to satoshis for external transfers.