Coin Supply
ETH = 78.9 Mio
_______________________
BTC = 15.5 Mio
LTC = 45.3 Mio
DASH = 6.4Mio
XMR = 11.6Mio
sum = 78.8 Mio
Paradox: ETH has equal number of coins than the bigggest other cryptos in sum - now go and sum up the use(ers) ...
Topic: The Ethereum Paradox - page 18. (Read 99876 times)
Compromise to what?
Just one way to get the old main chain sync'd up
with all of dem smaht contracts exchanging messages
you know...
Anyway, what really matters is what happens when
rubber hits the road. It is likely that Ethereum will always
be a work in progress but then again what open source
project isn't (unless dead)?
59:00 - He (Szabo) wishes Ethereum would not switch to proof-of-stake. He speculates about combining proof-of-work with proof-of-stake, but gives no details.
I've thought long about this issue before. Since mining is inherently a futures market, there are many ways you can try to replicate this feature, either with time opportunity costs, or proof of burn combined with strange economic systems. Most of the methods of trying to do so with time opportunity costs just replicate some form of proof of stake and create another closed entropy, permissioned ledger like all proof of stake coins. However, you might be able to utilize proof of burn and some weird economic system to combine the two while still being an open entropy, permissionless ledger.
I say "weird economic system" for a reason, because the last time anyone tried making a coin like this was "Slimcoin", and I think people proof of burned half the entire money supply just for the fuck of it.
https://www.youtube.com/watch?v=tWuN2R2DC6c
Nick Szabo mentions Ethereum's "advantages" over Bitcoin at the 13:30min point. Unfortunately he seems to be totally oblivious to the technical criticism we enumerated in the Ethereuem Paradox thread.
Edit: his pitiful defense of Oracles starting at 33:00min convinces me he is not grounded in any sense of reality of adoption.
Nick Szabo mentions Ethereum's "advantages" over Bitcoin at the 13:30min point. Unfortunately he seems to be totally oblivious to the technical criticism we enumerated in the Ethereuem Paradox thread.
Edit: his pitiful defense of Oracles starting at 33:00min convinces me he is not grounded in any sense of reality of adoption.
See also more discussion at around 01:00:00.
58:00 - Block chains can't out perform Tx/sec of Visa w/o losing the trustless attribute. I will challenge him on that with my white paper and argue that we can't have the trustless attribute w/o scaling!
59:00 - He wishes Ethereum would not switch to proof-of-stake. He speculates about combining proof-of-work with proof-of-stake, but gives no details.
01:00:00 - he doesn't seem to recognize that Oracles entirely break Nash equilibrium. Sounds to me like they are just ignoring that this will only work with centralization.
Without knowing the details, this seems to me a viable
compromise.
compromise.
Compromise to what? I can't see that addresses any issue we raised in this thread. I am not going to reexplain the thread again and why that doesn't address it.
Months ago I mentioned the asynchronous cross-partition
protocol, but no one commented.
Without knowing the details, this seems to me a viable
compromise.
Eagerly awaiting to learn how horrible it is...
protocol, but no one commented.
Quote from: Vitalik
More specifically, you can send cross-shard messages without restriction, but they're asynchronous, and you have to wait for a global state root to at least partially confirm before continuing each step of asynchronous execution. That's enough to allow parallel processing.
https://www.reddit.com/r/ethereum/comments/4d6i9k/sharding_vs_sidechain/d1odcr9Without knowing the details, this seems to me a viable
compromise.
Eagerly awaiting to learn how horrible it is...
ether is becoming dash type of cult of bagholders believing and denying real world and new coins taking over
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.)
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.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?).
Doge isn't actually referencing total coint count anywhere though, so it doesn't matter. All Doge does is say, this block we will unload a dump truck of Doges of whatever size on your doorstep, then the algorithm will gradually decrease the size of the dump truck until reaching a minimum of 10,000. Maybe if a single block reward exceeded 2^53 you might run into some issues, but no coins do that. The Bitcoin coin count is modeled more around value of 1 satoshi should it become a world reserve currency than other issues like this that can be side stepped.
There is no issue with 2^53 inside the coin code itself, which never uses floating point. The issue would only be with quantities handled externally.
DOGE is still divisible to 8 decimal places, so 2^53 is only around 90 million DOGE; not very much.
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.)
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.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?).
Doge isn't actually internally referencing total coint count anywhere though, so it doesn't matter. All Doge does is say, this block we will unload a dump truck of Doges of whatever size on your doorstep, then the algorithm will gradually decrease the size of the dump truck until reaching a minimum of 10,000. Maybe if a single block reward exceeded 2^53 you might run into some issues, but no coins do that. It's all for external systems to deal with.
The Bitcoin coin count is modeled more around value of 1 satoshi should it become a world reserve currency than other issues like this that can be side stepped. It was decided going vastly lower granularity than 1 penny wouldn't be needed or desired in regards to dust, so this put coin count + initial decimal places around a certain range. Who wants to purchase something and then type in 10 decimal places for the bill afterwards, all of which have no actual value?
Doge also has it's own anthropic principle. The coin granularity looks almost like it was designed by god himself with magic numbers to benefit strong arm market manipulators. So is Wolong a product of Doge, or is Doge designed for people like Wolong.
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.)
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.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?).
The issue is not with the coin itself but with external systems that process coin amounts. Yes that can be an issue with those other coins, if those external systems use floating point, which as I already explained it is a bad idea (and jstolfi added the condition that the programmer also doesn't understand how floating point works, which I would note is unfortunately extremely common).
In theory even 64 bit integers can overflow too though. COBOL used packed decimal, meaning storing one digit in each half of a byte, and arbitrary precision by using sufficient bytes to store values of the necessary range (defined by the programmer). This is slightly inefficient but avoids all hidden overflow and rounding issues.
Today programmers are often lazy and use whatever numeric types happen to be convenient be it floating point, 64 bit ints, etc. In some better written code occasionally you do see bigints/bigdecimal or even numbers stored as strings but that is rare.
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.)
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.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?).
cloning code is always a security issue for the system
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.)
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.)
Based on the above, should there be any attack vectors or exploit for altcoins like dogecoin, which went beyond 2^53, issuing in the hundreds of millions or billions? (Litecoin should be slightly below 2^53). If they are just cloning code that wasn't meant for their use case, perhaps vulnerabilities exist or arise at some point (?).
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.
[...]
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.
[...]
I replied to a private message reply from jstolfi @ Reddit:
Quote from: myself
I agree on probable necessity of centralization.
Blockstream's motivations may be multifarious. I presume money. Probably ego. Perhaps love of over engineering because solving difficult problems is a badge of status on the intellectual totem pole? Down the rabbit hole are wild conjecture and conspiracy theories. Occam's Razor probably applies.
Blockstream's motivations may be multifarious. I presume money. Probably ego. Perhaps love of over engineering because solving difficult problems is a badge of status on the intellectual totem pole? Down the rabbit hole are wild conjecture and conspiracy theories. Occam's Razor probably applies.
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.
Quote
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.
If you are just going to store integers (such as satoshis or cents), there is no point (with modern CPUs with fast 64 bit integer operations). If you store fractional currency amounts such as cents then you will run into all the various pitfalls that make using floating point for currency a bad idea.
Also, Python does not use floating point for all numbers. Maybe some very old version did, but since 2.x it has 64 bit ints and that is 15 years old.
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.
Quote
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.
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.
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.
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.
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 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-JavaScript
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.
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:
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%.
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.
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.
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.
Jump to: