Also it will get reviewed by really smart people such as gmaxwell
That
German idiot isn't qualified to evaluate anything:
I think it is not a valid argument because many implementations may not correctly implement the more obtuse seeking without an index. Thus we get the worst of both worlds.
I just don't buy this notion that we should dumb down and make inferior standards, because people are lazy to write and test software properly. Geez did Vint Cerf follow that theology when he design TCP/IP? Did we conflate all the network layers and collapse them into one layer because the OSI model is complex. Hell no! The End-to-End Principle is fundamental!
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%.Did you also forget that I (@AnonyMint) was the one who pointed out to gmaxwell that his CoinJoin proposal was flawed because it could be jammed and he argued that a blacklist could be employed and I explained that the entire point of anonymity meant blacklists would be useless. Ever since then he has been trying play an ego battle with me and he lost.
Then when Evan announced DarkCoin (Dash), I was the one who reminded him of this jamming problem and so Evan invented masternodes because of my posts in his announcement thread. Yep that was me. You've all forgotten.
You fools go on idolizing the guy who has totally destroyed Bitcoin.
One Idea. it already exists. BTC Debit card. never worry again. miners can use a bitcoin debit card to pay for their electricity. therefore keeping bitcoins security up.
Dude the point was that if the TPTB has shut down the financial system then that fiat linked crap isn't going to function. I agree with ZeroSum that Rickards' thesis is probably oversensationalized, but the point remains that Bitcoin is very much dependent on fiat.
Apparently the main purpose of Bitcoin's existence right now is avoiding capital controls in China:
... This would be especially true if we get any rumor out of China or India regulating Bitcoin further for capital controls. I don't expect it since Bitcoin is such an irrelevant small market cap, but Armstrong seems to think otherwise (yet he is not a Bitcoin expert and is always harping on this end of cash theme):
https://www.armstrongeconomics.com/world-news/taxes/bitcoin-what-next/