Fluffy looks less fat here, appears he is big boned and wider than tall. Spagni so he is of Italian descent? Evan looks younger in that photo than in the Evolution presentation. There is no doubt he comes across as an amiable person which is why initially I did not desire to put great effort into criticizing Dash's technology when it was first launched. I had even commented that he was very amiable. But haven't we all learned by now what a wolf in sheepskin is. When Evan gives up the instant mine and masternode control, then we can conclude he has turned over a new leaf. I noted fluffy stated he wasn't against the masternode conceptually as long as the barrier to entry wasn't so high. Well if he meant deposits which basically boils down to PoS, then apparently fluffy doesn't understand block chain security very in depth. I must admit I am jealous of these guys youthful age, good health, and thus able to get drunk. I absolutely can't drink any more (fatty liver disease) and I am not healthy enough to enjoy life normally. I was thinking when watching the video what it used to be like when I could waste time and energy on frivolous slapstick (although perhaps one could argue the camaraderie is useful for building synergies on projects, although I never found that to be true BEFORE open source at least). Really put in perspective what a shit life I have now. I fight for each morsel of production and energy. I can't waste, yet I do on this forum. I need to hang a mirror on the wall in front of me. I look so damn thin and unathletic in the pics I took today compared to January 2015. Embarrassing. |
|
|
|
I wanted to add something about the "rascist" allegation. I once attended an all negro elementary school in Baton Rouge, Louisiana, USA where my sister and I were the only non-negro students in the school. The kids had never felt fine hair, so they were constantly rubbing my head from behind (in the halls, etc) when I wasn't looking. I learned that negros have oily hands. I am far from rascist, as I live in the Philippines and have a brown skinned gf. I have kids who are half-filipino. But what is more interesting to me is your generation is so ideologically preoccupied. Perhaps you believe in the lie of anthropogenic global warming as well. I hate to bust your bubble but it was a propaganda constructed to put in a place a global governance and taxation system. The scientists have confirmed we are headed into a Mini Ice Age and our global temperature is modulated by the sun, nothing else. Period. You are also similarly naive about who controls Bitcoin and what their objectives are for global control. You are just a pawn Gregory. I hope you wake up and use your talent to fight for freedom, which means don't stomp on others and fall victim to incorrect perceptions which you want to enforce on others. I wish you the best. |
|
|
|
I am closing this topic (at least until there is something other than a vaporcoin to talk about). I did manage to get the fresh air working room environment set up, which will be much healthier than being in a room 24 x 7 with airconditioning and no windows. Late reply because I was constructing a wooden cage to hold a ceiling fan since the house I rent is so poorly designed that there are no wall nor ceiling studs capable of supporting a ceiling fan. So I lost most of the day being a carpenter without power tools.
  I wanted to add something about the "rascist" allegation. I once attended an all negro elementary school in Baton Rouge, Louisiana, USA where my sister and I were the only non-negro students in the school. The kids had never felt fine hair, so they were constantly rubbing my head from behind (in the halls, etc) when I wasn't looking. I learned that negros have oily hands. I am far from rascist, as I live in the Philippines and have a brown skinned gf. I have kids who are half-filipino. But what is more interesting to me is your generation is so ideologically preoccupied. Perhaps you believe in the lie of anthropogenic global warming as well. I hate to bust your bubble but it was a propaganda constructed to put in a place a global governance and taxation system. The scientists have confirmed we are headed into a Mini Ice Age and our global temperature is modulated by the sun, nothing else. Period. You are also similarly naive about who controls Bitcoin and what their objectives are for global control. You are just a pawn Gregory. I hope you wake up and use your talent to fight for freedom, which means don't stomp on others and fall victim to incorrect perceptions which you want to enforce on others. I wish you the best. |
|
|
|
I mean the tech is great and promising
Please justify that incorrect claim with a sufficiently elaborate presentation of technological understanding. Otherwise please stop contributing to the P&D by making claims that you are not qualified to make. |
|
|
|
A defense against this would be to mark the multisigs that are being used as anchors. Rather than 2 of 2, you could use 2 of 3 with the 3rd key being a standard value.
You can then set k based on how many trades are happening on the altcoin chain.
Attacker can make anchors for nearly free (large transaction values relative to transaction fees): ...but then an attacker can DE trade to himself to fool your algorithm into an unbounded value of k (as high as the attacker wants to make it).
|
|
|
|
|
I was underwhelmed by fluffypony as a charismatic, visioned, inspired, killer-instinct leader. Hard worker I presume. Reasonably astute I presume. Perhaps smarter than what can be detected from that boring slapstick interview. Much fatter than I expected. But no Steve Jobs, Mark Zuckerberg, Bill Gates type of personalty as far I can detect in the video.
His point about life & death is silly melodrama. Not business level thinking. Anyone who thinks posting this video is going to help Monero and hurt Dash, has been drinking too much.
Disappointed I didn't get to see smooth on video.
No offense fluffy. I am happy Monero is getting some attention. You've apparently worked hard. Perhaps the open source (no one is a superstar, many contributors) model will be the winner. I doubt it.
|
|
|
|
Gmaxwell is definitely correct that you have to factor in many variables, and the fact that those with higher hashrate waste less hashrate on propagation and verification delay is one of the factors. I did come to the conclusion that profitable mining will always centralize. There is no decentralized solution for as long as mining is profitable. No one seems to talk about the fact that the Chinese mining cartel controls 65% of Bitcoin's hashrate, has vetoed every block size increase (even Classic's doubling apparently)[1], and surely their hashrate share will increase on the next halving, because marginal miners are the first to go. Then they provably lie to us by claiming the Great Firewall of China is their justification, but they could put a pool abroad and just send hashes across the firewall. So obviously they want to fatten their oligarchy profits by forcing transaction fees up. (I am even more conspiratorial and assume they are getting free electricity charged to the collective State for a wink and a handshake). I predicted the block size issue and Tragedy of the Commons of mining (with a focus on block size) in 2013 and was routinely labeled loony. [1] Bitcoin has already been 51% attacked then. |
|
|
|
Late reply because I was constructing a wooden cage to hold a ceiling fan since the house I rent is so poorly designed that there are no wall nor ceiling studs capable of supporting a ceiling fan. So I lost most of the day being a carpenter without power tools.The container is very efficiently seek-able over the network, in fact. But your implementation must be sufficiently intelligent.
Here are some benchmarks from the opusfile library, On a 25 hour long variable bitrate audio recording performing 1000 jumps to exact sample positions with no caching:
Total seek operations: 1873 (1.873 per exact seek, 4 maximum).
So an average of less than two operations, and in the worst case 4-- meaning even with a 100ms RTT a worse case seek will not cause a noticeable delay. (and obviously, if it cached, it would be much better).
I am not an expert on streaming media and have just begun my research, but it seems to me that your quoted benchmark is assuming many seeks will be done on the stream. But there are cases where the user wants to only skip once or twice into a song as they are sampling the music for the first time, which is my use case. For that case, the lack of an index is afaics horrific because there will be the latency of some roundtrips required to optimally locate the seek position (by a bisection sampling method) and wasted bandwidth as well. No, it is assuming the user will make exactly one seek. Otherwise, it would assume caching. The expected accesses given are what you would get for a user that makes only a single seek. I can't find the details for this benchmark any where on the Opus website. I presume you are expecting that I would have to download, install, and build from source and then study the source code to understand what the benchmark is actually measuring. That seems to be an inappropriate level of work for an interested person to do when they simply want to get a reasonable first-pass analysis of the performance issues. As you know, the devil is in the details. I don't know for example if the benchmark is using some heuristics to reduce the error for estimation of the file position for seeks given it has been given 1000 trials. Also where you wrote "jumps to exact sample positions", I don't know if you mean the jumps are to exact positions in time and thus estimations of file position. Also I don't know the frame size that was employed (i.e. I know Opus goes as low as 20ms but this increases the overhead) and whether that is a significant factor. I think I read that an entire page much be downloaded before the checksum can be computed, to be sure one doesn't confuse garbled data with a frame header. I presume the error in estimation would increase if the sound content was highly variable in complexity and thus the VBR encoding would generate highly variable file positions relative to desired seek position in time. I am wondering if the 4 seeks worst case would hold. What if it climbed to 8 seeks! I didn't check how large the page size is, so I don't know if bandwidth wasted is a significant factor with erroneous seeks in the file position. In any case, one certain error in your analysis appears to be that you presume the internet can be modelled with a mean latency (e.g. 100ms). The internet I presume has hiccups and I presume the latency is Gaussian distributed. Thus 1 or 2 extra round-trips (e.g. 100ms each direction ideally, and worse from the Davao, Mindanao where I am) could be the difference between an unnoticeable delay of for example 500ms or a noticeable delay of 1+ seconds. And the occasional 4+ seeks, could mean up to seconds of delay. What may be more compelling is the extra load on the server, the hard disks thrashing, and also the latency of the server on each seek. Perhaps this has already all been studied exhaustively, but unfortunately I can't find that data with Google, so it appears to me to be another set of risks. Adopters have to factor in risks in their assessment. You could have instead made the index optional.
This is also not a free choice. In existing formats with optional indexes _no_ commonly used software is able to correctly seek when the "optional" index is not present. Many have no support for that case at all at all, and what has support in theory doesn't work due to inadequate testing. This was a similar argument made by the IETF group working on the Websocket framing protocol when I argued they should make the framing orthogonal to the data layer. I quit because they were not going to change their mind and I presume they did not adopt my proposal.
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%. Seems you are excluding use cases.
What use case is excluded? I have alluded to scenarios in this post. Permute them. And there are use cases that neither of us are aware of. We are not omniscient. We should not top-down remove degrees-of-freedom. Some of the people designing Web standards these days are doing it wrong and are not of the same pedigree as Vint Cerf. I butted heads with them in the past (including Ian Hickson!), and I am tired of arguing with you guys. Just do what ever you want, I am going to route around the failure. Moreover-- what error is there in having a streaming container that is actually good at streaming? People can use other containers if they need other properties.
Because it is very difficult to get new standards widely promulgated. The cost of not having Opus supported well for use cases. I will probably end up using Opus and having to roll my own client side instead of using HTML5 (which means my stuff will work best only on Android and not in the browser and probably not as well on iOS at least at the start). So I am very thankful for the work you did on Opus if I go that route. But I just think you should acknowledge to yourself that you are really awesome at your core competency, but you math guys need to allow guys like myself to participate in the standardization process for high-level issues. I have worked for example on what is now Corel Painter (the natural media paint tool not Corel Paint). Meaning I have dealt with the masses (Painter-J shipped a million units in the 1990s for example). Here is an example of where I promised Mozilla they were shooting themselves in the foot and they obstinately refused to listen, even after dozens of developers complained as I promised Mozilla would happen. (Though ironically, the best supported non-streaming container that is widely used with Opus-- MKV-- which has 'optional' indexes, on average requires transferring more data to seek a single time than Opus in Ogg does; due to the need to transfer the whole index to seek only once). The height of flexibility is acceptance that not every goal can be optimally satisfied in a single design.
Perhaps their index is very high resolution, very lengthy stream, and/or there is no option to break the index up so not the entire index is put at the start of the file (all of which could be fixed with a better protocol design and specification). I provided my computation above for a 495 byte index. Hey I have absolutely no experience at all with streaming. I am doing this all in my head for the first time. I think that exemplifies that I am an experienced coder and designer. Hey I understand what it is like to deal with trolls and in that case I would support the swift action since trolls only aim to disrupt, but I wasn't trolling you.
I have no clue what you're going on about here. I responded politely to your message here-- are you referring to my non-amusement to your wall of insults, allegations, and personal attacks that you cross-posted to several threads; when you couldn't find your own post when it had been moved to offtopic? I apologize if my abrasive response makes you feel threatened enough to need to expound on your best racist theories; but I have had several of our best posters in the past tell me they stopped using Bitcoin Talk because of harassment by you in particular, and its certainly a situation I've felt myself. You may not intend to troll; but your radical jumps into insults and attacks combined with your persistence and the stream of consciousness diving into incoherent technobabble arguments which you sometimes present is effectively indistinguishable from trolling. I and others have expended a lot of time trying to encourage better behavior under your now-banned past identities, without success. All that is left is to say that if you are unable to behave yourself and not act like a troll, you will be banned. Otherwise you won't be. The choice is yours. My reply is here. Gregory I worked for Tom Hedges on Painter and he could memorize a page of the phone book by looking at it for few moments. His IQ was off the charts. He would send me 1 sentence directives and it was up to me to figure out what was all reachable from that one sentence. What may seem incoherent to you is perhaps because you are not investing the time to follow links and the discussion that has taken place. It is inane to suggest I should re-type everything I already typed over and over again just so that no one has to follow a link. Actually Gregory, several times I have felt I respect you and admire your work and even presentations. Obviously I do, because I want to use some of your work. And I've learned important things from you. I have already explained what seems to rub me the wrong way. I don't know how to fix that, other than to stop interacting. Btw I think I did actually figure out how to remove the proof-of-square in CCT (but perhaps I have a math error but I have looked it several times and can't find an error but it just seems too simple and I don't know how you guys could have missed it, so there must be an error). I will release the white paper where I had combined CCT with CN rings back in June/July. But I want to reorganize the paper a bit based on some insights I gained from the discussions with Shen-noether. As for the politics, never mind (insoluble). People will think what ever they think. I have my justifications and reasons, but it isn't worth trying to convince others of my side. It is time for head in the sand, coding. Thanks. Talk is cheap as you know.
|
|
|
|
otherwise I fear that crypto ccy will never reach next level of investments and stay nichy by burning small people money that just have NO clue about proper risk management.
I think I know what needs to be done and I think I have the knowledge and skills to do what needs to be done. But words are cheap... silence is golden... |
|
|
|
Now you claim this is only isolated to a flawed DE script and I say that there are unbounded number of unknown scripts which may expose similar ways to fund 51% rented hashrate attacks. Thus it is a generalized security hole.
In the same way that there are an unbounded number of unknown apps/programs on regular computers which may also be faulty and which, when they become a dependency of another app, cause the other app to fail. No you fail to understand the salient economics distinction. Apps failing doesn't impact the economics of the security of the PoW that protects the block chain. Again it seems most people fail to incorporate economics in their assessment of block chain technological decisions. Assuming what you say above is correct you have nonetheless already stated it can be fixed.
Therefor if you are correct I assume it will be fixed.
You are punishing of Ethereum claiming wasted resources and failure to fix the real problem. Yet you openly advocate MAID
No it can't be easily fixed, because no one has yet figured out how to apply zk-snarks to a Turing complete scripting. I think it may be plausible, but I haven't looked at the nitty gritty details of that. As I wrote upthread, Ethereum has been moving entirely the wrong direction towards PoS (which is utterly insecure and centralization) and sharding I explained upthread is implausible for Turing complete scripting block chains. And I have stated my reasons that all decentralized file storage paradigms are fundamentally flawed and offered a fixed design. I have criticized MaidSafe, Sia, Storj, etc. as being fundamentally flawed. I don't have enough time to continue correcting all the errors of readers who are incapable of living inside my head. My mind is moving much faster than I can possible correlate for all of you my 10,000+ posts. Sorry. I am not the unpaid personal secretary of every reader on this forum!No you fail to understand the salient distinction. Apps failing doesn't impact the security of the PoW that protects the block chain.
I don't see how there can be any effect outside the particular output involved in the double spend. You think about it until you realize. Sorry I am not paid to spend all my time in forums explaining to the slow minded. |
|
|
|
Quite astonishing. Especially, that gmaxwell is a super intelligent individual. When I talk to people about Bitcoin here in the UK I often point out that the best software developers of our industry work on BTC and one of the bests is gmaxwell. I am not sure why he navigates himself into this situation.
Oh come now. TPTB made a totally offtopic post-- had nothing to do with Bitcoin at all, and only anything to do with the thread in question is that the rust language was mentioned in the thread and TPTB made a one sentence comment that he previously had complaints about rust but didn't remember them-- and it got moved to another subforum; where.. in fact, I wrote a polite reply to his commentary on audio codecs. TPTB's response was to go on a campaign of insults and allegations; spreading conspiracy theories and such; instead of just looking in his post history to see that the post was still there. His immediate recourse to attacks creates a hostile environment. Most thoughtful people have better things to do than to deal with that, myself included. If you'd like to continue to share a forum with "the best software developers of our industry"-- then you should step up and ask people like TPTB to relax on the attacks, not shake your head with him in agreement when someone else doesn't completely lie down and take a pile of abuse. Gregory now you are lying (or lacking reading comprehension or refusing to read/ignoring information again). See the red text:
Note this copy is being copied all over the place so it can't be deleted.
Your post wasn't deleted. It was entirely off-topic (going on about an audio format, in a thread about a cryptographic protocol.. had nothing to do with Bitcoin) and ended up getting moved to the off-topic subforum: https://bitcointalk.org/index.php?topic=1378533.0 . I even responded to it. I failed to see how (even if my comment about using Rust is considered off-topic, which also seems to be arguably relevant to jl777 asking if the source code is in C and your reply that it is in Rust and C++), that the following comment is off-topic and why it deserved to be removed from the thread within 60 seconds of my posting: Btw, I applaud the effort to develop zk-snarks for smart contracts. I believe it is absolutely necessary per the revelation in the "cut & choose" thread which if you think about actually has implications for any scripting on a block chain.
I am glad to see the post ended up some where. Unfortunately you were very slow to provide any indication of where the post had been moved to, orders-of-magnitude slower than your frantic < 60 second effort to remove my post from your thread. Hiding something? Don't want your reputation to be in doubt?
And Gregory isn't as smart[omniscient] as you all think he is. He can start by understanding the importance of that sentence he censored and the private msg I sent him which he claims was incoherent. Once he digests that, he will realize Bitcoin's scripting is flawed! For the dumbass trolls in this forum who think Gregory is absolutely smarter than me in every facet, I have a surprise coming for you... As for the polite reply Gregory refers to, I want to draw attention to his deletion of Come-from-Beyond's post (within seconds/minutes of it being posted, but I just happened to be reading the thread) and Gregory closing the entire thread after that post from Come-from-Beyond made it more clear that Gregory had been both technically incorrect and had railroaded another PhD. He did the same to my post and didn't even message me nor leave any link in the former thread, so I had no way to know where the post had been moved to and thus I rightfully assumed it had just been deleted. The point is that since he did not provide readers any indication that he had deleted and moved a post, we all have no way to verify if he actually did respond politely at the time, or whether he went into damage control mode later and later reposted my post to Off Topic and tried to be polite after the fact. Normally I would take a person at his word, but Gregory's past behavior causes me to suspect him to be a snake (some contagion of overly zealous control freak, superiority complex, earned destiny bcz for example Adam Back invented Hashcash, combined with vested interest of thinking he and his cohorts own Bitcoin or something like that... I haven't exactly figured out their thinking/disease yet). Note I have already acknowledged Gregory's apparently very exceptional work on the Ogg Opus sound codec. My (only high-level, superficial) understanding it this was a fabulous improvement in sound codecs and it is a shame it isn't more widely used:  Perhaps one of the reasons (other than the politics around patents and Apple's refusal to adopt it), is they apparently fucked up the Ogg container format (but note discussion between Gregory and myself is ongoing on that point so the final conclusion is not yet decided in my mind). I have also acknowledged Gregory's reasonably expert cryptography work (but I would still rate Berstein as much more prolific if not also more accurate, yet Gregory has also made some astute points about for example the type of ECDSA that Bitcoin uses). Gregory's background in number theory math and encodings is far superior to mine. But this is ostensibly a pigeon-holed background that apparently doesn't reach well into economics and the many other aspects of software design (or perhaps it is just personality trait of Gregory and/or a prioritization methodology he has chosen). Whereas, I have produced commercial software for millions of users more than once. I normally would have great respect and admiration for a person of Gregory's abilities, but his Hitler-like activities have turned me into his nemesis. When he comes down off his high horse and treats all people with mutual respect (except for trolls), then I can begin to admire him as my fellow cohort human being. As for the claim that I am hurling insults, thus far I have seen no clarification/retort from Gregory about the information I dug up about Segregated Witness which seems to indicate that Blockstream is attempting to plant a Trojan Horse in Bitcoin. If he has posted a rebuttal some where else in the forum, I eagerly await a link to it. Am I hurling insults or truths? Was Gregory hurling insulting lies or truths? I expect the truth will lie some where in between, and the source of the misunderstandings is Gregory's overzealous conviction that he is rarely incorrect. I understand very smart people develop a natural insulation from trolls and tend to think everyone is an idiot until they can prove otherwise. I try to listen to everyone. It is painful and causes me a lot of lost time due to so much noise that I have to wade through, but it also affords me insights that others pompously miss. Also it seems Gregory never learned the value of Mea Culpa. |
|
|
|
You have failed to read the linked thread and understand the issue. Please report back after you have read the linked thread (not the Monero thread) and understood how a certain script can open the security hole for a rented 51% attack: I had read that link but concluded that it was largely concerned with DE transactions; which boils down to a faulty script but that script not affecting the security of the chain in general, but only the funds involved in the script in the worst case. Casper aside, I still don't see how programmable scripting in general weakens the security of the entire chain; if anything it's analogous to the cascade of invalidations related to the particular output of a double spend. Only that script and related scripts are at risk. Okay I am going to explain this one time for those who weren't able to extract the salient point from what I wrote in the DE thread that I had linked to. And then after this post, I don't want to discuss any more shit on this forum (no insult/blame intended to those who have tried to have productive discussions with me including monsterer, which has been helpful and my sincere thanks is accorded in spite of any intermittent difficulties in attaining mutual comprehension). The problem is that once you enable the ability to put hashes of private keys on the block chain and enable multi-sig where revealing those keys allows a designated party to spend the transaction to any one, when this depends on the order of confirmations, then it opens a way to fund 51% rented hashrate attacks. Now you claim this is only isolated to a flawed DE script and I say that there are unbounded number of unknown scripts which may expose similar ways to fund 51% rented hashrate attacks. Thus it is a generalized security hole. The only ways to close the security hole are to only allow miners to run scripts which have been vetted and authorized, but that then centralizes the control. The only decentralized solution I can think of is to use zk-snarks to run the scripts in a black box in homomorphic zero knowledge so that miners can't see the data stored on the block chain. The only other solution would be analyze all the permutations of Op codes and be sure that all culprit op codes were removed. This is why I had sent a private msg to Gregory Maxwell, yet he says my msg is incoherent, because he didn't even take the time to understand, because I allege/observe he is an overconfident cocky destroyer of Bitcoin and destroyer who knows what else (in spite of apparently being very proficient at designing efficient algorithms for sound compression and apparently also reasonably expert at cryptography and much more so than me at both of those). Ethereum's even more generalized scripting will be much more vulnerable to this. The security hole funds an attacker to 51% attack a coin. This affects not only the unwinding of derivative transactions (which could span most of the coins if the attack is lie-in-wait long enough) and also impacts all the coins in terms of loss of value due to the market reaction to a 51% attack and also enables the attacker to do some double-spending while he is attacking. Also we can't characterize all the types of scripts which might create such losses and thus be directly impacted by stolen coins. |
|
|
|
You have failed to read the linked thread and understand the issue. Please report back after you have read the linked thread (not the Monero thread) and understood how a certain script can open the security hole for a rented 51% attack: I had read that link but concluded that it was largely concerned with DE transactions; which boils down to a faulty script but that script not affecting the security of the chain in general, but only the funds involved in the script in the worst case. Casper aside, I still don't see how programmable scripting in general weakens the security of the entire chain; if anything it's analogous to the cascade of invalidations related to the particular output of a double spend. Only that script and related scripts are at risk. Okay I am going to explain this one time for those who weren't able to extract the salient point from what I wrote in the DE thread that I had linked to. And then after this post, I don't want to discuss any more shit on this forum (no insult/blame intended to those who have tried to have productive discussions with me including monsterer, which has been helpful and my sincere thanks is accorded in spite of any intermittent difficulties in attaining mutual comprehension). The problem is that once you enable the ability to put hashes of private keys on the block chain and enable multi-sig where revealing those keys allows a designated party to spend the transaction to any one, when this depends on the order of confirmations, then it opens a way to fund 51% rented hashrate attacks. Now you claim this is only isolated to a flawed DE script and I say that there are unbounded number of unknown scripts which may expose similar ways to fund 51% rented hashrate attacks. Thus it is a generalized security hole. The only ways to close the security hole are to only allow miners to run scripts which have been vetted and authorized, but that then centralizes the control. The only decentralized solution I can think of is to use zk-snarks to run the scripts in a black box in homomorphic zero knowledge so that miners can't see the data stored on the block chain. The only other solution would be analyze all the permutations of Op codes and be sure that all culprit op codes were removed. This is why I had sent a private msg to Gregory Maxwell, yet he says my msg is incoherent, because he didn't even take the time to understand, because I allege/observe he is an overconfident cocky destroyer of Bitcoin and destroyer who knows what else (in spite of apparently being very proficient at designing efficient algorithms for sound compression and apparently also reasonably expert at cryptography and much more so than me at both of those). Ethereum's even more generalized scripting will be much more vulnerable to this. The security hole funds an attacker to 51% attack a coin. This affects not only the unwinding of derivative transactions (which could span most of the coins if the attack is lie-in-wait long enough) and also impacts all the coins in terms of loss of value due to the market reaction to a 51% attack and also enables the attacker to do some double-spending while he is attacking. Also we can't characterize all the types of scripts which might create such losses and thus be directly impacted by stolen coins.
Now you claim this is only isolated to a flawed DE script and I say that there are unbounded number of unknown scripts which may expose similar ways to fund 51% rented hashrate attacks. Thus it is a generalized security hole.
In the same way that there are an unbounded number of unknown apps/programs on regular computers which may also be faulty and which, when they become a dependency of another app, cause the other app to fail. No you fail to understand the salient economics distinction. Apps failing doesn't impact the economics of the security of the PoW that protects the block chain. Again it seems most people fail to incorporate economics in their assessment of block chain technological decisions. Assuming what you say above is correct you have nonetheless already stated it can be fixed.
Therefor if you are correct I assume it will be fixed.
You are punishing of Ethereum claiming wasted resources and failure to fix the real problem. Yet you openly advocate MAID
No it can't be easily fixed, because no one has yet figured out how to apply zk-snarks to a Turing complete scripting. I think it may be plausible, but I haven't looked at the nitty gritty details of that. As I wrote upthread, Ethereum has been moving entirely the wrong direction towards PoS (which is utterly insecure and centralization) and sharding I explained upthread is implausible for Turing complete scripting block chains. And I have stated my reasons that all decentralized file storage paradigms are fundamentally flawed and offered a fixed design. I have criticized MaidSafe, Sia, Storj, etc. as being fundamentally flawed. I don't have enough time to continue correcting all the errors of readers who are incapable of living inside my head. My mind is moving much faster than I can possible correlate for all of you my 10,000+ posts. Sorry. I am not the unpaid personal secretary of every reader on this forum!No you fail to understand the salient distinction. Apps failing doesn't impact the security of the PoW that protects the block chain.
I don't see how there can be any effect outside the particular output involved in the double spend. You think about it until you realize. Sorry I am not paid to spend all my time in forums explaining to the slow minded. |
|
|
|
You have failed to read the linked thread and understand the issue. Please report back after you have read the linked thread (not the Monero thread) and understood how a certain script can open the security hole for a rented 51% attack: I had read that link but concluded that it was largely concerned with DE transactions; which boils down to a faulty script but that script not affecting the security of the chain in general, but only the funds involved in the script in the worst case. Casper aside, I still don't see how programmable scripting in general weakens the security of the entire chain; if anything it's analogous to the cascade of invalidations related to the particular output of a double spend. Only that script and related scripts are at risk. Okay I am going to explain this one time for those who weren't able to extract the salient point from what I wrote in the DE thread that I had linked to. And then after this post, I don't want to discuss any more shit on this forum (no insult/blame intended to those who have tried to have productive discussions with me including monsterer, which has been helpful and my sincere thanks is accorded in spite of any intermittent difficulties in attaining mutual comprehension). The problem is that once you enable the ability to put hashes of private keys on the block chain and enable multi-sig where revealing those keys allows a designated party to spend the transaction to any one, when this depends on the order of confirmations, then it opens a way to fund 51% rented hashrate attacks. Now you claim this is only isolated to a flawed DE script and I say that there are unbounded number of unknown scripts which may expose similar ways to fund 51% rented hashrate attacks. Thus it is a generalized security hole. The only ways to close the security hole are to only allow miners to run scripts which have been vetted and authorized, but that then centralizes the control. The only decentralized solution I can think of is to use zk-snarks to run the scripts in a black box in homomorphic zero knowledge so that miners can't see the data stored on the block chain. The only other solution would be analyze all the permutations of Op codes and be sure that all culprit op codes were removed. This is why I had sent a private msg to Gregory Maxwell, yet he says my msg is incoherent, because he didn't even take the time to understand, because I allege/observe he is an overconfident cocky destroyer of Bitcoin and destroyer who knows what else (in spite of apparently being very proficient at designing efficient algorithms for sound compression and apparently also reasonably expert at cryptography and much more so than me at both of those). Ethereum's even more generalized scripting will be much more vulnerable to this. The security hole funds an attacker to 51% attack a coin. This affects not only the unwinding of derivative transactions (which could span most of the coins if the attack is lie-in-wait long enough) and also impacts all the coins in terms of loss of value due to the market reaction to a 51% attack and also enables the attacker to do some double-spending while he is attacking. Also we can't characterize all the types of scripts which might create such losses and thus be directly impacted by stolen coins. |
|
|
|
This makes them impossible to attack but it also makes them a sham. They're just centralized systems implemented in an inefficient way that gives the appearance of decentralization.
I couldn't agree more with that statement - a lot of people are being deceived with PoS, which is a great sham e. ftfy
Well you don't need to find historical keys (in order to rewrite the history of PoS block chains), when you can make them for nearly 0 cost.
Simply buy and sell on an exchange, and your cost will only be the spread.
Then short the coin, and start attacking.
Obviously this doesn't apply to illiquid meaningless microfloat altcoins. We are talking about whether PoS is viable for a mainstream decentralized coin. Not.
For a centralized coin, then anything works, you don't even need PoS nor PoW (except to fool people with).
max reorg depth in NXT is 720 blocks
Checkpoints are centralization. For a centralized coin, then anything works, you don't even need PoS nor PoW (except to fool people with).
If we don't have decentralization, then the entire plot has been lost. Do you need an example? Here you go (remember the Chinese mining cartel allegedly controls 65% of the Bitcoin hashrate): https://www.reddit.com/r/btc/comments/48nnaw/the_truth_comes_out_core_devs_have_convinced/ |
|
|
|
The fact that blocks would propagate to 90% of nodes in 2.4 minutes, would make it appear that my suggestion of a 3 minute block interval could be managed in the current structure.
Look up the equation for orphan rate so you can learn why your assumption is incorrect. |
|
|
|
|
Show Posts
