Hacker Newsnew | past | comments | ask | show | jobs | submit | nytf3's commentslogin

skateboarding is a very bad example here - there is a noticeable difference in the quality/bearings of a "beginner" equipment that comes from Walmart/Target that costs ~60, and a proper setup from a skateboard shop that costs ~120.

The beginner equipment is more likely to get you hurt by breaking, and the bearings will be very very slow.

For other sports, running/biking/skiing/etc I think this difference is not as pronounced.


It’s odd that you would end by assuming that other sports don’t suffer from the same problem. If you buy crappy shoes and run in them for extended periods you will hurt your feet and knees. If you try to bike harder than commuting on a cheap bike you’ll hurt yourself when the brake pads come loose. No idea about skiing but someone in this thread said they felt a noticeable difference, I’m not sure if it translates into safety though.


What are the advantages of Empirical vs q/kdb+?


Empirical is statically typed. I can run a backtest overnight knowing it won't crash because of a type error or misspelled column name.

I'm currently in the (long) process of adding streaming computation. Once that's ready, Empirical will be able to handle everything from gargantuan CSV files to real-time data using the same language primitives.

I talked about some of these goals when I launched on HN last year:

https://news.ycombinator.com/item?id=19969390


IOTA is vaporware and gives all blockchain projects a bad reputation by association. You are right on your points and forget that they rolled their own elliptic curve so you cant use a wallet twice.


Complete BS, of course you can use your wallet twice, but not the receiving seed, that's why you have to generate for each transaction a new seed.

EDIT: In other words every seed could just be used for one transaction...but that has nothing todo with your wallet-seed

EDIT2: And its not a elliptic-curve but a direct acyclic graph

https://en.wikipedia.org/wiki/Directed_acyclic_graph


Elliptic curves are a type of cryptography and directed acyclic graphs are a type of graph. They have nothing to do with each other at all.

Also all crytpo currencies are essentially DAGs that are synchronized by the ordering of the transactions by whoever mines the block. IOTA pretends that there is something different when the real difference is that they can't decentralize how to synchronize transactions.


Just half true, read for your self:

https://www.gibraltarlaw.com/directed-acyclic-graph-vs-block...

>can't decentralize how to synchronize transactions

No one ever said that, of course they have so synchronize to the network...what else? Entanglement?

>Elliptic curves are a type of cryptography

Yes and it was NOT a Elliptic curve but a type of winternitz-ots.


The point was that you didn't know the difference between where elliptic curve cryptography would be used and a directed acyclic graph. Also a ledger is by its nature a directed (one direction) acyclic (no cycles) graph of dependencies, it just depends how you visualize it. Just like instructions on a computer are in a sequence, they can be separated into graphs of dependencies which may be woven together.

Other crypto currencies are able to synchronize in a decentralized way with different miners mining each block. As far as I know IOTA's structure makes this impossible, even though when they created it everyone else had already done it.


elliptic curve is a type signing algorithm (like blake2b or sha). if you dont understand what an EC is i dont think you also understand why rolling your own would be a bad idea. the wallet/account seed (your post is semantics in my opinion, whichever seed it is you can only use once, which is a flaw) is directly related again to this issue.


Its not a elliptic curve but was a type of winternitz (Curl-P) before, then blackhat came:

https://i.blackhat.com/us-18/Wed-August-8/us-18-Narula-Heilm...

And then they changed it....and no you create a iota seed just like that:

cat /dev/urandom |tr -dc A-Z9|head -c${1:-81}

And talking about scam....ethereum-classic? Bitcoin-cash?

Your talking about a flaw when you just can use a receiving seed once? Please just read the DAG article, and understand what winternitz-ots means hint (one time signing)

EDIT: Here the winternitz paper: https://eprint.iacr.org/2011/191.pdf


the lack of awareness around nano is puzzling to me. I assume its because nano became known around the end of 2017 along with many scam coins, and thus became associated with them.

but today if you described implementing a gossip protocol with nanos features (permissionless decentralization, 0 fees, <1s tx), many people would say it is impossible, but here we are with a 4 year mainnet with no serious issues


im not sure why this is being downvoted. this is clearly the case here.

the user and the miner are colluding (or the same party). the user does not broadcast their tx publicly, only sending it to the colluding miner. since fees have no utxo history, this essentially launders the eth



Thanks for sharing, wasn't familiar with this body of work.


No problem! Not much of a pedigree, but I think the articles stand by themselves.


BTC fees are currently ~$2.50 (11PM EST 4/30/20)[1]

[1] https://twitter.com/CoinFees/status/1256045351024418821


tezos is attempting to solve this by incorporating on-chain governance - its dPoS and has a code deployment mechanism with a long voting process (multimonth). They have done 2? upgrades now and quorum seems to be ok so hopefully they can keep up voting %

i still think the nano (formerly raiblocks) approach is cool - it scales by running parallel blockchains - each wallet is its own chain. tx's between chains are voted on weighted by % stake - dpos without lockups or slashing. this way its not a competition for space in a single ledger, its competition for voting bandwidth on the worst marginal node. a better tradeoff imho. downsides: the ledger also grows larger quicker than btc (because theres no 7tps limit so you can spam it)

no voting rewards or inflation - theres no on chain incentives for voting at all, but exchanges/pos need to run full nodes to validate ledger anyway and voting is trivial bandwidth. its elegant and the security model works but its hard to tell people about without coming across as a fanatic.


Because nano has free transactions, a big concern was indeed spamming the network because transanctions are free (as in you pay no nano). But since each wallet has to calculate their own blockchain, the prosessing power is purely on the client side and so not free in that sense, which limits the spamming to the processing power you have.


Recent spamming [1][2] has seen nano ledger size balloon by nearly 50%, negatively affecting full node Initial Block Download times as well as archive node disk space requirements. The PoW requirements go up with network congestion, but at this rate of 5-8 tps are quite minimal.

[1] https://nano-faucet.org/stats/

[2] https://nanocean.org/ (Click on Live Stream)


Cool writeup! Although I agree those captcha's are fairly trivial.

In college I wrote a term paper on breaking Microsoft's captcha (which is a little harder but not by much) twice: first with a simple template-based classification method and then a CNN approach.

https://www.dropbox.com/s/jfp5xbv3eh589f6/6_857_CAPTCHA.pdf?...

At the end, we go over approaches that would help captchas fight attacks. I think the quick flickering approach would work best (split the image into uneven parts, flicker them quickly so the human eye can read the aggregate image but any single slice doesn't show the full picture, and the superimposed image is incorrect)


Cool idea and thanks for sharing!

One of the challenges here (which I'm sure you are very aware of) is that perception tricks that fool computers like flickering images also can block out users with different types of visual impairments. Sometimes users with even minor or infrequently-symptomatic visual impairments won't be able to read an image[1] that uses a special "trick" like this.

For example, consider the risk of triggering an epileptic seizure with flickering. At a certain point it becomes an accessibility/legal issue.

[1] The animated example from nytf3's paper - please note that in contains strong flickering: http://people.csail.mit.edu/recasens/images/captcha.gif


Would flickering even be necessary? Why not just overlay several transparent GIFs/PNGs? It’s still hackable (so is the flickering solution), but you could also add in a few more tricks to make it more work for the hackers. For example, combine the layers dynamically into a single image with a separate HTTP request to retrieve the (random) positions of each layer within that image. (Just a thought...you could make it as simple or as complex as you want.)


At that point, you could have your captcha-breaker wait for the page to finish rendering, screenshot the relevant portion of the page, and solve from there. Seems easier than trying to download and stitch together the transparent GIFs or decode the jumble of HTTP requests.


That seems more like security by obscurity - as soon as somebody realises you are doing that, they can visit your site with headless Chrome and break it easily.


But whatever process the human eye uses to piece together a flickering image should itself be fairly simple, right?


couldn't you just capture a sample of frames and take the mean ?.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: