|
AlexGR
Legendary
Offline
Activity: 1708
Merit: 1049
|
|
April 04, 2016, 06:51:43 PM |
|
@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: What happens if, say, hardware behaves differently in certain computation: https://en.wikipedia.org/wiki/Pentium_FDIV_bug#Example_symptomsWould a script like that, which executes a certain division that produces different outcomes in different machines, fork the network? Or are math functions software-emulated for safety and not speed?
|
|
|
|
tromp
Legendary
Offline
Activity: 990
Merit: 1108
|
|
April 04, 2016, 07:11:52 PM |
|
Would a script like that, which executes a certain division that produces different outcomes in different machines, fork the network? Or are math functions software-emulated for safety and not speed?
Ethereum has no built-in support for floating point data types...
|
|
|
|
AlexGR
Legendary
Offline
Activity: 1708
Merit: 1049
|
|
April 04, 2016, 07:25:04 PM |
|
lol?
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 05, 2016, 05:19:02 AM |
|
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.
|
|
|
|
AlexGR
Legendary
Offline
Activity: 1708
Merit: 1049
|
|
April 05, 2016, 10:12:44 AM |
|
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.
|
|
|
|
tromp
Legendary
Offline
Activity: 990
Merit: 1108
|
|
April 05, 2016, 01:14:58 PM |
|
I found it extremely hard to believe that floating point can't be supported. Floating point is required in a lot of financial transactions.
Fixed (decimal) point suffices in most cases, which is easily represented with integers. Bitcoin fractions have 8 decimal places and thus we can represent arbitrary BTC amounts as integer multiples of 10^-8 BTC (satoshis).
|
|
|
|
finitemaz
Member
Offline
Activity: 88
Merit: 10
|
|
April 05, 2016, 03:08:12 PM |
|
Strange that partitioning is listed as scaling option #2 now and scaling option #1 is the exact same thing as Bitcoin .... Solution path 1: lightning networks / state channels (eg. Raiden) ● Solution path 2: sharding (Ethereum 2.0)
And LN won't work without scaling because it has a huge periodic garbage collection spikes in block size headroom. So it is back to an insoluble problem for both Satoshi's design and Ethereum, Isn't LN what they're currently proposing for bitcoin? https://www.reddit.com/r/Bitcoin/comments/4dg9rz/bitcoin_lightning_network_should_be_ready_this/
|
|
|
|
TPTB_need_war
|
|
April 05, 2016, 03:23:51 PM |
|
Please don't stand in the way of Blockstream clusterfucking Bitcoin. It is a necessary stage of the evolution of crypto currency.
|
|
|
|
finitemaz
Member
Offline
Activity: 88
Merit: 10
|
|
April 05, 2016, 03:31:06 PM |
|
Please don't stand in the way of Blockstream clusterfucking Bitcoin. It is a necessary stage of the evolution of crypto currency.
Is the LN proposal that outlandish? Forgive me, I am far from an expert on this.
|
|
|
|
|
jrpatking
|
|
April 05, 2016, 04:11:31 PM |
|
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.
|
|
|
|
finitemaz
Member
Offline
Activity: 88
Merit: 10
|
|
April 05, 2016, 05:56:22 PM |
|
Well why the hell are they even bothering with it then? Clueless?
|
|
|
|
stoat
|
|
April 05, 2016, 06:28:13 PM |
|
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.
Well said 👍
|
| FREEDOMRESERVE | Free currency for the British Isles Visit our website for more info <-- Click here! | | FREEDOMRESERVE By the People and for the People |
|
|
|
finitemaz
Member
Offline
Activity: 88
Merit: 10
|
|
April 05, 2016, 06:37:37 PM |
|
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.
Well said 👍 Shilly you. That was terribly said if anything.
|
|
|
|
TPTB_need_war
|
|
April 05, 2016, 07:52:51 PM Last edit: April 05, 2016, 08:19:38 PM by TPTB_need_war |
|
Well why the hell are they even bothering with it then? Clueless?
(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. And gmaxwell got his ass handed to him by myself in that debate on the Ogg container format for which he was the co-inventor of one of the key codecs: 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.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 05, 2016, 08:04:57 PM |
|
I found it extremely hard to believe that floating point can't be supported. Floating point is required in a lot of financial transactions.
Fixed (decimal) point suffices in most cases, which is easily represented with integers. Indeed floating point should almost never be used in financial transactions (unfortunately the programming error of doing so is made often). https://www.quora.com/What-is-the-best-way-to-handle-floating-point-problems-with-financial-calculations-in-JavaScriptHe 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.
|
|
|
|
AlexGR
Legendary
Offline
Activity: 1708
Merit: 1049
|
|
April 05, 2016, 08:32:00 PM |
|
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.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 05, 2016, 08:53:21 PM |
|
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.
|
|
|
|
JorgeStolfi
|
|
April 06, 2016, 04:11:34 AM |
|
Indeed floating point should almost never be used in financial transactions (unfortunately the programming error of doing so is made often).
Floating point is quite adequate for financial computations -- if the programmer understands how it works. According to the IEEE floating-point standard, that is used by all major makers since the 1980s, a double-precision float can represent all integers up to 2^53 exactly, with no rounding. It turns out that 21 million BTC is just below 2^51 satoshis. That means it is safe to store BTC amounts as doubles, and even do simple math on them, if one stores them internally as satoshi amounts, rather than fractional BTC amounts. (The only theory I know for why Satoshi limited the max issuance to 21 million BTC is that he knew this fact, and was aware that Excel, Awk, Python, Matlab, and many other languages and formats used IEEE doubles for all numbers, integer or real. Een though he did not use floating point in the bitcoin protocol, he must have felt necessary to accommodate those languages.) In the 1990s, smart programmers used floating-point to do integer computations, because the FPU multiplication and division units in typical CPU chips were much faster than the corresponding integer units. (I don't know whether this is still true today.) The infamous Pentium Divide Bug was discovered by a mathematician who used that trick in his investigation of some number theory conjecture. 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.
Yes in theory, but the full IEEE floating-point representation is quite complicated. Simulating it in software is no easy task. Fortunately, one does not need to understand any of that complexity when storing integers up to 2^53 or so.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
|