Topic: What is the right and fair way to stop Mike Hearn? - page 11. (Read 14041 times)

But they can run fake Tor nodes today, without doing any work at all. And as I pointed out, nothing stops you from picking nodes run out of different countries. The NSA might be able to fake US passports just fine. If they can get the Russian and Chinese private keys, well .... at least all the incentives are right to make that hard.

It really can't make anything worse. You can easily run multiple nodes off one passport. Just don't expect the same wallet app to connect to more than one of them. Tor has the notion of families, it maps naturally to that.

You're really going to have to work to sell your idea... This isn't a friendly business arena you're operating within and people are used to being screwed sideways.

I'm not saying you operate the same way but you still have to convince people that you aren't.

There's no irony in handing control of those systems to government. In a fantasy world these passport certificates aren't subvertable - they'll always be issued honestly, never duplicated, and the private keys in them will stay in them - but in the real world that's not something you can guarantee. People are worried that we'd find out in a few years for Snowden Jr. that the (three-letter-acronym) had been making up fake passports for the purpose of running Tor nodes - certainly possible - or had been issuing passports that they actually had the secret keys to after all and were signing anonymous signatures using that fancy crypto-math to run said Tor nodes.

Or hell, if this is one-passport-one-tor-node I'm sure these large surveillance/police/military government bodies could just ask their employees to donate their passports briefly to a good cause...

Anyway, two out of three of your examples have better solutions to them; notably there's no need to trust nodes to be "honest" anyway.



Something really interesting re: TPM is it appears you can make open-source community audited remote-attestation-capable hardware. The trick is that you can build hardware that creates the secret keys after manufacturing in some kind of initialization process, yet have the process itself verify the integrity of the "strong-box" the computer is in, and have the hardware implementing that process be designed such that third-parties can take it apart and verify that the hardware would have done that honestly. Pulling off this trick requires a minimal bootstrap routine in ROM that creates the keys on startup - since it's ROM you can pull the circuit itself apart to verify that the ROM was guaranteed to be executed and thus the keys generated securely when the internal batteries were connected the first time.

As for the "strong-box" to provide the tamper resistance, tempered glass and mirror silver work well. The glass is notoriously difficult to breach without causing it to shatter due to the internal stresses, and mirror silver lets you make tamper-detection circuits that detect that shattering and wipe the internal keys. Both techniques are low-technology, yet effective.

Now to verify the remote attestation, you take production lots of these boxes, have third-parties select sample boxes and tear them apart looking for flaws. The chance of getting away with shipping a bugged box is some function of how many sample devices were audited, the size of the production lot, and how good you are at detecting bugged devices. A secondary audit technique is to put Bitcoin private keys in the devicse, pay coins to them, and see if any get spent!

I spent some time a few months ago going through some of the details and think I covered them in principle, but just didn't have the time to pursue the project. There's a lot of details to cover, most of them nitty-gritty hardware level stuff, and you're likely to end up with "reasonable" assurance rather than anything all that convincing. But for Tor routers that's not a bad start. Combine it with Mikes passports maybe for more assurance.  

There would be no link to your identity.

I think I'm going to have to find a simpler way to explain this. Maybe a diagram would help. A lot of people aren't getting it.

I don't have a passport. My wife doesn't have a passport. Nobody in my extended family has a passport that I'm aware of.  

I don't think they're as common as you assume they are. You don't need one unless you travel out of the country and in these economic times I bet the number of people travelling is decreasing.

Thank you for working on improving the network but the closer Bitcoin is to digital cash; the better... We already have plenty of centralized and highly regulated options and we don't need Bitcoin turning into another one. There should be no link to your identity outside of a currency exchange for a centralized fiat currency.

The exchanges can deal with identity if you ask me...

If the solutions of today aren't satisfactory then wait for the solutions presented tomorrow. Don't just choose the least harmful out of a handful of poor solutions for lack of a good solution yet to be discovered...

The proof technique I referred to in the talk is indeed what Eli Ben-Sasson presented at the conference. PCP's are just a part of it. You have to convert a C program into an arithmetic circuit nd then convert that into a quadratic arithmetic program before you can start creating a PCP from it.

Trusted hardware can be OK, but I think techniques based purely on maths can ultimately be more trustable when applicable.

My approach to the solution would be to have a completely open hardware solution for TPM modules with design, manufacturing, and distribution overseen by a coalition including the likes of the EFF.  These would take the place of government issued passports, and would fit the bill of being relatively cheap, but not so cheap as to allow trivial mass accumulation.

To further gain confidence in the node distribution, employ methods like Kaminisky's 'nOOter' and Eli Ben-Sasson's 'PCPs' as presented at the SJ 2013 conference.

It's obvious you either didn't watch the video of my talk or didn't understand it. If you had understood it, you would know the difference between someone verifying their identity, and providing a zero-knowledge proof that they own a passport. These are entirely different things: the purpose of one is to avoid anonymity and the purpose of the second (what I was talking about) is to preserve it.

I must say, this is one of the most tiresome things about doing research on Bitcoin development - people who simply do not listen or understand yet have strong opinions anyway.

To summarise for other people who didn't/won't watch the talk: in a peer to peer network, there are times when it would be useful to know that the peers you connected to are not cooperating against you. This is obviously impossible to guarantee but we can make it significantly less likely with a variety of techniques, which we call anti-sybil techniques. Cases where it's useful to know this:

• Unconfirmed transactions with lightweight clients with no trusted third party, i.e. SPV clients like MultiBit, the Android wallet or Hive. Once you get a confirmation or two you can put your faith in majority hash power, but with Bitcoin as it works today, until then you have to just ask a bunch of peers if they believe it's valid. If you think you're talking to the real P2P network but in fact you're talking to a man in the middle attack, you could be misled into believing in a transaction that isn't valid.
• For floating fees, you need to poll random peers. You can't rely on the block chain here because it's being created by the parties that have most to gain from lying about fee levels.
• In Tor, you want to pick nodes/relays that aren't cooperating because if they were they could deanonymize you and Tor wouldn't work.

None of today's solutions are satisfying. Bitcoin Core relies on picking nodes spread out across a big range of IP addresses, but anyone with a botnet can beat that. SPV wallets (bitcoinj) just ask the DNS seeds and hope they're doing a good job, but DNS is insecure and the responses could be faked. Tor places much less emphasis on decentralisation than Bitcoin does and relies on a kind of central control by a group of "directory authorities", which can (and do) ban nodes.

So I discussed a couple of other solutions. One is proof of sacrifice, also known as fidelity bonds. For a while I called them "anonymous passports" but given the second line of research this name is ambiguous so I don't call them that anymore. Basically you throw some money away to miner fees and then use the Bitcoin addresses associated with that transaction to prove it was you who did it. With such a scheme if someone wanted to bring up 10,000 bitcoin or Tor nodes that were all run by the same person, that'd be very expensive.

But we don't want running Bitcoin or Tor nodes to require expensive sacrifices. We want them to be as cheap and numerous as possible. So, I suggest a second line of research - use some very advanced and modern mathematics to create a mathematical proof that you possess a passport (the government issued kind) without revealing any information from it. You would literally produce just a mathematical proof that you own a passport which hashes to a certain value. This does not require any co-operation from governments, it just processes data they already issued and they can't stop us doing it. This idea is useful because most people have one (or maybe two/three) passports, but it's very hard to own 10,000 of them. So you can easily get good diversity of nodes, and it's hard for Joe Hacker to flood the network with botnet bitcoinds that screw around with our system. Same for Tor.

Some people have noticed that although this approach would stop a large variety of different attackers, governments could make fake passports and use them. Yes, this is true. However they could also run fake Bitcoin/Tor nodes today too, so it's not making things any worse. And in fact there's a neat move we can make here too - an interesting thing about this new mathematical technique is you can potentially (I think) selectively reveal particular fields, like the country. So your wallet app could pick nodes run by citizens of the USA, Germany, China, Russia and Brazil. Because the worst attacks require the majority of nodes to be bad, this is strong - even if the USA decides to mint a pile of fake passports they still can't do anything bad. It'd require all those governments to co-operate to flood the network, which is a massive upgrade over the situation we have today.

Glancing at Reddit I see comments like "this is a statist solution". I guess a few people don't appreciate the irony of inverting an infrastructure of government control, to build strong anonymous peer to peer networks.

Half these people work on 100 things at a time. I understand that because the code isn't modular yet, that is why, but still Mike Hearn does nothing for bitcoind anymore his time is focused on Bitcoinj and now being an advisor on the board of circle his time will be cut even more so no he has nothing to do with anything right now.


So why isn't this being pushed to the front? Look Kryptokit made messaging in PGP extremely easy so don't give me the standard it is too hard for regular people speech.

TOR integration is potentially dangerous at this stage because it's very low hanging fruit for media outlets/vested interests to attack.

If we delayed TOR integration until bitcoin has gotten over many of these attacks regarding its 'anonymity' and 'links to criminal organisations', then they won't be able to lump us in with 'paedophiles' and 'arms traders' quite as easily.

You're misinterpreting his point about passports. He was using it as an example of a trusted centralised token.

https://blog.conformal.com/redecentralization-robust-developer-network/

Yes, SPV clients and micropayment channels are preposterous!  

Edit: I just heard that he's working on getting Tor on by default for Bitcoin wallets as well!  What a monster!

If I thought code was what mattered most, I might, you know, actually write some.

+1

I think that Todd is ignoring/ignorant of a lot of the forces that are shaping the trajectory of the solution and placing to much emphasis on the actual codebase.  External factors tend to have a much bigger impact on a project's trajectory than code, and there is now a LOT of interest in Bitcoin from a lot of different directions.

Also, I wanted to get an entry in this thread to more conveniently follow it

You guys don't hang around github much:

Enable tx replacement on testnet. (closed)

Drop fees by 10x due to the persistently higher exchange rate. (not getting merged)

Gavin doesn't have magical merge-by-fiat powers either:

Remove hard-coded fee rules (closed)

Relay first-double-spend transactions (not getting merged)

Nor does he have magical powers over the Bitcoin Foundation bylaws:

Add promotion and protection of decentralization to purposes

Even in the centralized development structure arguing things intelligently goes a long way, and when your ideas get rejected in that central repository you can always take them elsewhere, or even to a different currency altogether.



Pieter Wuille is doing the bulk of the work getting pruning implemented actually. It's just taking awhile because the changes he needs to make to the networking code to enable it are quite complex and risky - he's already had to throw out his first attempt at solving it.

As for other scalability issues, Gregory Maxwell, Adam Back, Andrew Miller, Mark Freidenbach, and yes, Mike Hearn are all working on various aspects of the problem, among others. It's just a very, very hard problem.


OpenPGP is actually most interesting, and obviously valuable, for the person-to-person case; you're money would do good things there. (Dark Wallet people are interested in this too fwiw)



People who do development, control development...

Wrong.

Yes you are the only working on it, and I surprise this isn't bigger issue. It should be something that should be worked on by all the top devs. "They" are the foundation and no I am not going to start an argue about how the foundation has nothing to do with the bitcoin codebase, which we all know at this time isn't true.

Good that litecoin did that, I can't wait for Bitcoin-OMG to release that since bitcoin-qt isn't going too.

Lets be honest peter we all know that no one is going to use the openPGP code, bitpay has already come out in support and that will make their merchants use that and coinbase (which I love and have great support for) is going to use it since Gavin is on the board. I mean to implement openPGP code would waste my funds and my time.

People who control development control the future of Bitcoin. Better get used to it.

If PGP is a nonstarter, what would your preferred solution be to the problem which SSL integration purports to address?