Earlier quoted context omitted.
Larry from Blockstack. We used use Namecoin and migrated to Bitcoin when we discovered that one miner controls more than 51% of mining power which is a security problem in a proof of work blockchain. If you're interested in learning more, there's a peer-reviewed paper on it here: https://blockstack.org/blockstack.pdf Section 3: "Lessons from Namecoin Deployment" may be of interest to you. There's also an (old) thread…
Bitcoin mining is also controlled by a small number of people. Over 50% of the blocks hashed over the last 4 days are from the same 5 pools. [1] The difficulty mechanism has been an abject failure and utterly destroyed bitcoin's promise of decentralization. Under that mechanism, commodity mining hardware automatically defeats itself. We now have a small number of big players who've built custom, super-secret hardware…
Improving on Tor .onion Address Usability
31–40 of 40 posts
Re: Improving on Tor .onion Address Usability
#32The way DNS works in I2P[0] is pretty neat[1]. Nothing in this post sounds quite like it. It provides a great "default" user experience while allowing for finer-grained control and tighter security if a user chooses. To summarize: - Users have a local "Address Book" which maps friendly names (e.g. forum.i2p) to I2P destination keys. - There are well-known I2P hidden services providing address book subscriptions. The…
Does that mean when a site links to "forum.i2p", then it's up to your own local address book where that actually goes? (Assuming people don't use the ?i2paddresshelper thing for literally every link, unless that is what is done.)
Another thing I forgot to mention: if a name is unknown, your local HTTP proxy will ask you if you want to try to lookup the name from one of several popular "jump services", which are the same services providing address book subscriptions. This is where jump links come from most of the time.
Re: Improving on Tor .onion Address Usability
#33The way DNS works in I2P[0] is pretty neat[1]. Nothing in this post sounds quite like it. It provides a great "default" user experience while allowing for finer-grained control and tighter security if a user chooses. To summarize: - Users have a local "Address Book" which maps friendly names (e.g. forum.i2p) to I2P destination keys. - There are well-known I2P hidden services providing address book subscriptions. The…
It's similar to what ideas 2.1 and 2.2 are in the blog post - a local directory that is maintained and authenticated centrally and then distributed to browsers that perform a central lookup. The downsides are that it is too centralized - it isn't difficult to imagine that a government agency would want to sinkhole silkroad.tor from the default registry. With an alternate registry, you have the balance between knowing…
It is only centralized for users with the default install, who never go into their address book.
I think the real achievement of I2P's name system is that _they have made it easy for users to understand_, and the tight integration in the UX is the main differentiator I see between I2P's approach and any of the approaches in this blog post.
While I think Namecoin sounds cool and all, I really hope Tor considers a simpler approach. I think it's a mistake for us to make this into a technical problem, when it's a UX problem. We're never going to get 100% secure names in a trustless environment, so why not focus on making the default pretty secure, and making the system understandable and useable?
Re: Improving on Tor .onion Address Usability
#34Earlier quoted context omitted.
Bitcoin mining is also controlled by a small number of people. Over 50% of the blocks hashed over the last 4 days are from the same 5 pools. [1] The difficulty mechanism has been an abject failure and utterly destroyed bitcoin's promise of decentralization. Under that mechanism, commodity mining hardware automatically defeats itself. We now have a small number of big players who've built custom, super-secret hardware…
50% of hashrate coming from 5 pools doesn't sound like centralization to me. Afaik many pools don't even have miners themselves.
It hasn't been a problem so far, but having so much of the network under the same jurisdiction is just inviting trouble.
Re: Improving on Tor .onion Address Usability
#35Earlier quoted context omitted.
Bitcoin mining is also controlled by a small number of people. Over 50% of the blocks hashed over the last 4 days are from the same 5 pools. [1] The difficulty mechanism has been an abject failure and utterly destroyed bitcoin's promise of decentralization. Under that mechanism, commodity mining hardware automatically defeats itself. We now have a small number of big players who've built custom, super-secret hardware…
50% of hashrate coming from 5 pools doesn't sound like centralization to me. Afaik many pools don't even have miners themselves.
In short: the pool still defines the blocks that the connected miners will mine. They centralize all the collective power of all connected miners.
Re: Improving on Tor .onion Address Usability
#36I realize the task of recording your favorite .onion names is a small expense of keeping your traffic private, but why is "taking notes in a text file" considered ad-hoc now? That wasn't the case in 1990, where most computer users had a library of floppy drives with their personal documents, notes, and records. Has the world truly forgotten that you can store data in textual form to your computer's filesystem? With h…
Good point about the filesystem, but this sounds like a really annoying and slow task to have to manage manually. If someone wants to write an app that spares me the drudgery of copying and pasting out of a text file every time I want to go on a website, I will use that app. Not to mention the reduced cognitive load from having fewer open windows to manage, and one less thing to have to know where I put it.
This doesn't help with the potential complexity of sharing or remembering (on a new device) the sites of course.
Re: Improving on Tor .onion Address Usability
#37Why not use Namecoin? Seems like a good fit.
Larry from Blockstack. We used use Namecoin and migrated to Bitcoin when we discovered that one miner controls more than 51% of mining power which is a security problem in a proof of work blockchain. If you're interested in learning more, there's a peer-reviewed paper on it here: https://blockstack.org/blockstack.pdf Section 3: "Lessons from Namecoin Deployment" may be of interest to you. There's also an (old) thread…
https://namecoin.org/docs/faq/#how-does-namecoin-compare-to-...
Re: Improving on Tor .onion Address Usability
#38Earlier quoted context omitted.
Does that mean when a site links to "forum.i2p", then it's up to your own local address book where that actually goes? (Assuming people don't use the ?i2paddresshelper thing for literally every link, unless that is what is done.)
I don't know how i2p works, but isn't that pretty much they way the "normal" net works? If you click a link to "news.ycombinator.com" in your webbrowser, it's mostly up to your local or ISPs DNS resolver where that takes you, no?
Re: Improving on Tor .onion Address Usability
#39Earlier quoted context omitted.
Bitcoin mining is also controlled by a small number of people. Over 50% of the blocks hashed over the last 4 days are from the same 5 pools. [1] The difficulty mechanism has been an abject failure and utterly destroyed bitcoin's promise of decentralization. Under that mechanism, commodity mining hardware automatically defeats itself. We now have a small number of big players who've built custom, super-secret hardware…
50% of hashrate coming from 5 pools doesn't sound like centralization to me. Afaik many pools don't even have miners themselves.
That's all handled internally. The Bitcoin network sees the pool as any other node; there is a hard stop there. It doesn't know that the answer was found by compounding the hash power of many servers.
As another commenter said, that alone is a risk, because you have (presumably) thousands of servers masked behind 5 central brokers. They are, in effect, the centralized banking cartel, and the pool participants are like their branches, ancillary components that are used to help perform the work, but which ultimately are at the mercy of those in the central office.
Consider that in late 2015, at the Scaling Bitcoin Hong Kong conference, the managers of all of these pools met together to attempt to devise a strategy for the blocksize problem. The controllers of what at the time was over 90% of btc's hash power were in the same room. [1]
Since miners stand to benefit from a limited blocksize and normal consumers stand to suffer, you can guess where their interests aligned. How is this different from the executive teams of the large banks getting together and agreeing to collaborate on other efforts?
Less likely, but much more worrying, is the question of what would've happened if the Chinese government incidentally decided to declare running a bitcoin pool illegal that day (I know that HK has an independent-for-now government, but Beijing has made incursions before, and is getting increasingly aggressive as the 50-year integration timeline narrows). These people could've been arrested and their resources could've been confiscated.
Beyond the concerns of a pool operator getting compromised, we also have to worry about the general matter of pool transparency. There's no way to see whose hash power is being contributed into the pool (afaik). We don't know how much of that hash power is from independently-operating nodes. Guaranteed very little of this is occurring on commodity hardware; most of it is in data centers in China, running custom mining hardware.
Initially, people attempted to produce and distribute consumer-level miners, but that has more-or-less burned out because the ROI is immediately decimated. There is still a small amount of interest in it for the novelty, but no one expects to make money from it.
As soon as the network gets an appreciable increase in hash power, like that which would be precipitated by the wide distribution of fast miners, the miner becomes worthless at the next difficulty evaluation. That's how the protocol works, and it means that consumer-level bitcoin hardware is a pipe dream.
The incentive is clearly to develop the fastest hardware possible for oneself, and then to prevent as many others as possible from getting something similar. This means proprietary hardware. Custom ASICs are extremely expensive to develop, especially at small scale, and only the biggest players are going to be able to do this. btc long ago blew away CPUs, FPGAs, and GPUs.
I don't think that was the intention, since it obviously leads to centralization and secrecy, exactly the problem set btc was trying to solve.
Since we can't see into the pools, we have no way to know where that hash power actually lies. It'd be very dumb to fire up uber-secret hardware with unprecedented hashing performance and not pretend that there's a pool in front of it. It's possible, I would even say likely, that a huge portion of the hash power in these pools comes from a small number of big contributors, potentially even the pool's operators themselves.
btc was originally envisioned as something everyone would run on their home computer, and it would be as decentralized as the internet was. Due to multiple design flaws, it's failed horrendously in that, and is now very centralized (and not just in mining).
I know there are a lot of nuances to btc and I don't claim to be a btc expert, so after you downvote, please correct me. ;)
[1] https://news.bitcoin.com/scaling-bitcoin-workshop-hong-kong-...
Re: Improving on Tor .onion Address Usability
#40Earlier quoted context omitted.
Not with a programatic standard I can't. I'm saying they should make the equivalent of key server for GPG -- something simple. Problems with relying on a blockchain to validate domains against sophisticated adversaries range from obvious to unknown. Not good.
The problems related to blockchains are very well known. Blockchains have been used extensively at this point, for highly critical applications. They're the most censorship resistant platforms known to exist.
I'm stoked about blockchains as much as anyone else (heck, I quit a job at Google and spent a year playing with them when Bitcoin first came on the scene). But to say that they are a good thing to build on top of when facing adversaries that have 7 figure USD budgets and capabilities to perform active attacks on non-trivial chunks of the internet strikes me as just a bit naive.