HN user
Check the reference client buglist, they got hit with a slowloris resource exhaustion combo. They fixed the resource exhaustion (kind of), they did not address the slowloris vulnerability. So again, you have no idea what you're talking about. Doubly so if you didn't write the backend of a major mining pool - because you're just running your mouth about code you haven't seen otherwise.
Where is the contradiction?
I said that you can't verify the header until you have downloaded the entire block - meaning the time between a false header being submitted and the last transaction in the block being downloaded is time the miner either abandons its work on the last real block and then sits idle or risks hashing a new block prior to verifying the false header. He implied that you can somehow verify using the PoW. I demonstrate that you cannot. I'm not sure how you could have missed it.
lol, I marked every tenth led manually and counted twice - the number is correct, the marketplace is wrong.
https://www.mblock.com.tw/upload/Investor/events/2020/202008...
What are you even talking about here? 900KB takes a fraction of a second to transfer on a modest internet connection...
You are assuming that there are no bad actors in the network who might not want to transfer a block in a fraction of a second, and don't have to because they control the packet rate. Also you seem really hung up on this 900KB figure, you've repeated it in 8 recent posts. You know bitcoin's 30 day average block size has been above 900KB since 2018-10-24? But why would you harp on bitcoin's block size when you are advocating for a max block size that could accommodate all of Visa's transactions? Is is because you know that a 300MB+ block guarantees the death of decentralization and you'd look ridiculous pretending otherwise? To quote you before you presumably exchanged your BTC to double down on your bcash airdrop:
"Once again, whatever people's views on bitcoin at least realize that mining hashes don't dictate how many transactions can be processed by a miner. They mine a block, then they include as many transactions as they think they can get away with and keep the latency low enough to propagate."
2016 -- https://news.ycombinator.com/item?id=11689765
...a VPS can transfer that is a millisecond.
Ah yes, that has worked out great for several exchanges and various other cryptocurrency related services. The cloud has been great, fill it with all the things.
No one said anything about downloading fractions of blocks, you hallucinated that.
You don't seem to understand how packet switched networks function either. Go lookup "MTU", I look forward to hearing how even the most modest internet connection enjoys IPV6 with a 300MB jumboframe policy spanning the entire network path!
Why do you think 32MB or more would be anything other than trivial to send and receive? Any miner can send and receive that in a second.
Except for everyone transiting a sub 256mb peering point... so alot of people: https://www.peeringdb.com/advanced_search?info_traffic__in=0...
It isn't that it'd take them 10 minutes to download the entire block... it is that they are at a 0.92 second disadvantage to their competition - this drives the physical centralization.
Bitcoin cash already has more sustained transactions than bitcoin. Maybe you should reach beyond the propaganda of /r/bitcoin
lol, the salty salty tears.
Miners that do that take the risk that someone else will propagate a block before them since they didn't share the previous block they found.
And yet they do it, because it has been mathematically demonstrated to be a winning strategy - even before block bloat induced propagation delay. The rest of the statement is simply nonsensical.
In your last message you compared something with a 10 minute window to millionths of a second. For some reason you ignored this and ignored the actual numbers of modern bandwidth. You keep using hyperbole but won't quantify anything because the numbers don't add up.
Yeah, you clearly don't understand the comically simple idea that a consistent head start on your competitors guarantees eventual domination. The 10 minute window is completely immaterial to the point. If you can consistently verify the newest announced block 1 second before every other miner - then your average solve rate is guaranteed to be 1 second faster than their average solve rate.
Where are you getting ideas like this? How fast do you think internet connections are?
As fast as the packet source wants? The only way to defend against a slowloris DoS is by accounting for it at the application layer, which is both unusual and difficult - as DoS attacks are usually handled at the transport layer. In this case that could mean applying a deadline for the block announcement in its entirety - which means mandating a minimum connection speed, and classifying every connection that dips below that as an attack... so you better have a good SLA with your upstream network. Well, that is no problem for centralized operations... Guess what happens to cryptocurrencies that adopt massive 128MB+ blocks in order to increase their transaction throughput - they become incredibly fragile as the slightest amount of packet loss starts waves of peer bans.
Who are these miners that are struggling to send out 900KB ?
Anyone who wants to handicap a competing pool by forcing them to either wait for the complete false block, or waste time hashing on a fake block header.
When are you going to admit that you haven't thought this through?
I'm unclear on where you got 104x78.
https://www.alibaba.com/product-detail/Hot-sale-small-pitch-...
Module Res Size
P1.923 104*78 200*150
Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW.
Ok, I guess you don't know how verification works. Here are the 19 steps: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messag...
Step 4) "Block hash must satisfy claimed nBits proof of work"
Step 10) "Verify Merkle hash"
Unless I'm misreading the page, it is claiming a resolution of 104x78. So that means 8,112 LEDs.
The HDSP-2132 is made of 8 character elements, each element has a resolution of 5x7. So a 80x24 terminal would have a resolution of 400x168... 67,200 LEDs.
So about a magnitude off, even before ignoring the built in character spacing :)
You are overlooking the disadvantage of not verifying the prior hash, which you can't do until you can verify hashMerkleRoot, which you can't do until you have collected the entire block. If you skip verification, you open yourself up to bad actors feeding you a bogus header - and you only figure that out after being drip fed a bunch of transactions that don't match the merkle root. Erasure coding doesn't fix that. In any case, proponents of the 'cram everything in the public ledger' method have already advocated 128MB and even completely uncapped block sizes... so the outcome is predictable.
Take a hint from every successful network that has ever networked since ever: hierarchy, extensibility, etc. Demanding that it all be crammed into a homogenous block is so obviously doomed to fail that you should be suspicious of the proponents' motives.
What numbers are you basing that on? Bitcoin is 1.5KB/s.
You know you can't verify an incomplete block, right? If you think you can just plow ahead after getting the first packet... you are going to have a really bad day once the other miners notice that you can be fooled into wasting hash power on bogus headers. You know that blocks get announced by the miners after they solve the hash, in chunks that can be up to the max blocksize, right? For Bitcoin that is 1MB, for bcash it is 32MB. Imagine if NASDAQ offered two levels of service: one that put the FIX protocol behind a 1MB buffer, and the other behind a 32MB buffer - which one would be disadvantaged? Anyone sitting at the 32MB buffer would be getting their lunch eaten. This is about as fundamental as it gets, so you might want to do some reading - because you've clearly got a big blindspot.
No they don't. The examples you are talking about are rare and have very little impact.
If you are talking about bitcoin, you are very wrong - it is a thoroughly documented occurrence, it even has a name: the selfish miner strategy. If you are talking about bcash, I dunno one way or the other - I don't pay much attention to the joke coins. https://doi.org/10.1109/ICBC48266.2020.9169436
How long do you think it takes to send around 900KB ?
Again, you need to actually do some reading on how mining works and what the network propagation characteristics are. I really don't want to have this come off as meanspirited, but it needs to be said: you obviously thought you knew how things worked, and you obviously don't - I wonder how many people you've misinformed.
When you blow up the transaction limit you physically centralize the verification process. This is why you'd see miners gamble with sitting on a solved block and secretly beginning the next search, with a few seconds of head start, before announcing to the network, or skipping the inclusion of any transactions: because fractions of a second make a big difference. Bigger blocks propagate more slowly, and magnify the advantage of employing those kinds of undesirable behaviors. This is why HFT boxes end up as physically close to Wall Street as possible. This is also why bcash got so much early support from Chinese miners.
Yes, but they will be dealing with a currency that has mathematical guarantees - which changes things entirely. Imagine a scenario in which self driving cars are not only the norm, but they've achieved a perfect safety record due to an open source, formally verified, code-base. In that scenario, do you think the National Highway Traffic Safety Administration still needs 600 employees and a 900 million dollar budget? I have no doubt that it would still exist, but it would be addressing an infinitely simpler problem - and the reduction in resource requirements would cut it down to a skeleton crew that would operate much like stubcode in the wake of a refactor.
He was pretty upfront with the the possibility that his problems with rust were of his own making. The places he tried to leverage conditional compilation could be charitably described as "creative", and would raise eyebrows even in a language like C - where the preprocessor is relatively unconstrained. I'm not familiar with his project beyond the snippets he shared, so he may have had good reason to effectively ifdef inside a function call instead of any of the more traditional locations.
Oh and it gets better: known bad data is still repeated, despite the poster being told why it was bad data - over a year ago. Pointing this out results in flagging, for reasons that have nothing to do with ego or narrative continuity... surely.
I've never seen an estimate that withstood any kind of scrutiny. I've seen estimates based on both fundamental misunderstanding of the function of mining, and wild assumptions regarding miner behavior and out of date asic specs. Have you bothered fact checking any of those claims you just made? I mean actually reading the papers they cite, and learning the methodology they used. Because while you're thinking about conquistas, I'm thinking about the field of cybernetics in the 70's, and how it killed itself dead with ridiculously flawed methodology for modeling population growth - as the Davos types all nodded in agreement.
"Give me a one-handed Economist. All my economists say 'on the one hand...', then 'but on the other..."
-- Harry Truman
It has been done a few times, but I doubt there would be any kind of market for it. https://hackaday.io/project/85515-redotmatrix
Electroluminescent glass panels on the other hand... https://www.youtube.com/watch?v=Z2o_Sp2-aBo
Yeah, the HDSP-2132 is a common display component in military hardware. I'm sure that readability figures into it (especially for NVGs), but so does hardiness. My hopes of an 80x24 dumb terminal were dashed when I finally learned the unit replacement price... I don't need a rad hardened serial display that bad.
It is odd, I've been involved in the cryptocurrency scene from the beginning, and I've seen the whole "Bitcoin kills Mother Gaia" talking point pop up every couple of years - but I've never seen such prolonged parroting as this last cycle. It is a silly complaint, because it never considers the wastefulness of the status quo. But it is an interesting method of attack, trying to conceal the fact that it is a call for others to act against their own interests, while also tickling their envy. It could be a dangerous gambit though, while most people can't see far enough ahead to realize that global carbon caps effectively freeze the international market's structure, they can see when somebody is ham-fistedly screwing with their money.
Yeah, it isn't something that is feasible if you can't tailor the infrastructure to the underlying data. An SQL backend is about as generic as it gets, hence the poor results. Enterprise DB deployments get away with it because they can justify throwing a lot more hardware behind a centralized generic data store.
Give that second link a closer look if you change your mind. It demonstrates a way of indexing 1.6 billion 80B strings in 24GB, and then returning the result of a fixed string search in 100ms. That is the reward you get when you venturing outside of the LAMP stack: less resource consumption, greater performance, increased utility.
Yup, the most resource constrained form (PCRE2 would be the Cadillac-DoS-my-webapp option). I don't know how abnormal my problem is, but I've run into several cases where I needed a file that had a very specific naming structure - but a couple of substrings needed to be masked because that was the information I was looking for. That can easily be handled with two fixed string passes on a local file system, but not so much at the scale we're talking here.
As far as the indexing issues you mentioned, I'm not a python guy, so I can't recommend a drop in solution. But I have indexed pretty massive string datasets, and you definitely want to select an index method that was specifically devised for the key/value datatype you intend to ingest. So hashmaps are probably out :) It would also pay to adapt either the implementation or the data itself. For example, say you had a bunch of font file name you wanted to index (XyzSans.otf, AsdfSans.otf, AsdfSerif.otf, etc): a prefix tree would be a pretty good fit, especially if you reversed all the strings.
It would be very nice if you could search based on file name, as you can with btdig.com. If you could somehow provide BRE without melting down, that would definitely put you way ahead of the other DHT index attempts.
More an IBM archeology question: aside from the scattered projects to catalog specific product lines, are you aware of a more general effort? I've been pulling together a lot of their research papers and documentation related to the POWER architecture for a while, and I've noticed some pretty big missing pieces. For example: in order to best preserve the pdfs, while increasing their usefulness and reducing their maintenance burden (disk space), I set out to convert them to PDF/A. That means embedded fonts, which is fine - I'd ideally digitize as much of the text as possible (instead of throwing a hidden OCR layer on and calling it a day), but... the font is nowhere to be found. IBM had an extremely popular font, Press Roman, that is very common in journals and books published from the 60s to the late 80s, and as far as I can tell - it may now exist only in whatever remains of two printer font cartridge SKUs. I won't even get started on the problem regarding their plotting software.
It reminds me of how NASA simply lost so much of the original media, and what he have today is either purely accidental or the result of a considerable amount of work done by volunteer restoration groups. We really need to get a grip on this problem now, and it would be nice if IBM would actually help out with that - instead of leaving it to volunteers.
Funny, I was just over on ibm1130.org the other day - so the ALD diagram jumped right out.
analog techniques used in contrast-tracking
aka edge detection :) I don't remember if it was the Sidewinder or Walleye that eventually dropped in a CCD (or both), but I know that the Maverick (which is technically older than Walleye) got along without a CCD until the GWOT - when it finally upgraded. The Javelin actually beat Maverick in that regard, having a 64x64 sensor 10 years earlier - able to handle scaling and perspective change for the 2-d designated target pattern.
IBM has a very long history of diligent notetaking, maintaining several journals dedicated to internal development stretching back into the 50's. While I certainly haven't read everything, I've read enough to feel comfortable saying that the quality has had a sharp decline as transparent marketing replaced useful engineering. I suspect I'm not the only one who felt that way, because they recently shuttered those operations and tragically handed everything (from what I can tell) over to the paywalls. I generally don't feel much one way or the other about corporations, but seeing IBM decay like this genuinely makes me gloomy.
https://sci-hub.se/10.1109/4.45001 https://sci-hub.se/10.1147/rd.342.0416 https://sci-hub.se/10.1147/rd.342.0428
It is surprisingly easy to find, as that stuff is pretty thoroughly covered in academic/industry journals. The only hinderance to access is a credit card number for the paywall.
So I guess you've never heard of the AGM-62 Walleye, or anything else that came out of China Lake. Before you try backpedaling with some silly nonsense about how gating isn't real CV, maybe do a quick search through the journals that cover this stuff: aiaa would be a good start. Another path would be in relation to counter-counter-measures, and ground noise rejection for air-to-ground radar guided munitions. That stuff was deployed regularly all the way back to Vietnam.
Not in python, maybe. Smartbombs have been doing the necessary image processing with much less processing power, on much less capable sensors, for a long time.
lol, or potato chip bags... it is always a delight to see the bad guy step on a rake. Powerwords: CIA Italy Kidnap Potato
Or AMD could simply knock off the binary blobs. The DRM excuse has always been weak, because it is a tiny fraction of the total firmware blob - and it'd be easy to make it so that the legally hobbled hardware decoder simply errors out in cases where the end user chooses not to load the DRM blob. Boom, no more dependence on AMD interns. I've been following their commit logs pretty closely for a year now, and I frequently see some amazing accidental admissions about the left hand (software team) not knowing what the right hand (hardware team) is doing. During one very frustrating series of patches it was difficult resisting the impulse to say "Go get your dad."