Cubic Earth

I hope this turns out different than anyroll's 10 BTC giveaway.

He was worried that he would have been captured in Iceland before he had a chance to go public.  Iceland is small and the US can exert enormous pressure and maybe even have its agents operated directly there.  Hong Kong, under China's umbrella, would not suffer from those same risks.  Did you see that Snowden said he would have had to give the NSA 30-days of notice before he left the country?  He was worried he might not have even made it to Hong Kong without being nabbed right off the airplane.

Not so fast, bud, you don't have to lose! Compromised hardware, via firmware or bios attacks, or even malicious chip design is soon going to be a reality to contend with.  The digital arms race is just gearing up - especially as the recent surveillance disclosures have revealed - and bitcoin is in the heat of the battle.  As was said during the conference in San Jose, the state of our computer security systems, generally speaking, are barely ready to handle something as potent as bitcoin.  I know your right, that traditionally hardware has been assumed to be safe, and that that concept forms a basic tenet of security thinking.  Foreseeing the coming onslaught of compromised hardware though, I am trying to think of vulnerabilities and their solutions.

Having different pieces of hardware doing the same job in the security system, and then comparing the results with a third system, or having two or three different models of data diodes in a row are a few examples of how to protect against hardware attack.  It wouldn't matter if one element was compromised in such situations.

If bitcoin gets big, the security systems surrounding multi-billion dollar wallets will have to be as robust as the stuff that protects the nuclear launch system (or at least hopefully does).  If one can design a system that mitigates the risk of compromised hardware, that can help to shrink what is currently large attack surface.

You're talking about red/black separation. Ideally, your red box (the one you're accessing sensitive data on and which stores your keys) won't have any kind of network connection at all, instead using sneakernet to transfer encrypted data to and from your black box (which has a network connection, but never touches unencrypted data). It's the only way to be sure.
[/quote]

That is what I am talking about. The data diode would serve the same function as sneakernet, although the diode would obviously allow for the real-time and continuous transfer of data to the red system.  As I mentioned, several diodes could be placed in serial to multiply the chances of preserving security.

A firmware hack couldn't remap the pins?

Jeeze, the only friend who I called about this basically asked me the same thing.  I don't want to get on anyone's bad side, clearly there are lots of benign situations that demand super security and privacy.  I am interested in going through the theoretical exercise to see if I can devise a hack-proof system.  My main assumption is that my computers would be physically secured.


Your right Foxpup, there is no pushing signals down a wire when it comes to electricity, but I think this would be the case with fiber optics and light.

I was trying to design a crypto communications system where the private key would reside on a computer behind a data diode or two.  You would read the emails, chat, voice or video on that computers monitor.  All of your outgoing communications would be sent from a another computer, which of course would not have the private key on it.  The main stumbling block I have come to is how to verify that the outgoing packets, leaving the computer you are typing on, have truly been encrypted with the intended public key.  I am trying to anticipate software and hardware backdoors.  It would be really nice to have a way to sniff all outgoing traffic and verify that only properly encrypted packets were leaving the network, but without your friend's private key, you can't do the verification.  More thinking ahead!

The system is aware of maneuvers like that, and you don't need bitcoin to hide your assets.  Your strategy has been possible with gold forever.  They are not going to discharge your debts, however, it they determine that you assumed those debts with no intent to pay them back.  So if you sell you car, sell your house and take out a loan, put $100k on your credit cards and funnel it all into gold, and then declare bankruptcy, you'll probably just end up in jail.  Be prepared to flee to Mexico.

I thought about that technique, but I was wondering if some hack could remap the pins?  I know it would be really hard to pull of, but there are some very determined adversaries out there.  So I wondering if I do as you described, but also spice some actual diodes into whatever pairs, either the tx or rx, that are hooked up.  Then even if the pins were remapped the electricity could not flow backward.

I can see fiber being more secure though.  Even with diodes in copper, just because the electricity wasn't flowing backwards wouldn't stop information from leaking out.  You could always vary the electrical load in a specific way and the sending side could detect the difference.

I'm not sure I agree.  Wouldn't it be harder for an attacker to issue 5 2-minute blocks in a row than it would be for them to generate a single 10 minute one?  I can see it being easier to make 5 2-minute blocks in a row than 5 10-minute ones, but I think what matters is expected security after x amount of time.  After 30 minutes (approx. 15 blocks) with 2-min blocks you would be safer than 30 minutes with 10-minute blocks.

Its like a serial dilution when you are rinsing something.  Given a soapy jug and a one jug full of rinse water, if you just poured the rinse water into the soapy jug and then dumped it out there would be plenty of soap residue left (this being the 10 minute block).  If you take the rinse water and add a pint at a time to the soapy jug, slosh it around, and dump it out, and then repeat that 8 times, the soapy jug will be very, very clean (this being the 1.125 minute block).  The water is like our hashing power.  There are more and less efficient ways to use its properties for our ends.

I've been thinking about how I could construct my own data diode.  I know there is a lot to consider, but right now I am just curious about the physical layer.

Does anyone know if it would be possible to splice into some cat-5 cable a few actual diodes and still have the signal pass?  Or would they mess up the impedance, or something like that.  I know there are transmit and receive pairs, but perhaps they could be remapped somehow.  I would be cool if you could actually just buy some diodes and make your own one way cable.

+1

I would think they would just 51% the new algorithm as soon as it was agreed upon.  That is one of bitcoin's major advantages, it has by far the most invested in supporting hardware.  If they could muster the money and technological ability to compete with all the ASIC's it would probably be pretty easy to take down something else.  And you can bet they would have already planned for it.

We all acknowledge that a 51% attack is possible.  Maybe not likely, maybe not profitable, maybe stupid, but these reasons are not enough, not even when taken together, to stop an attack from happening.

Maybe this idea is already out there, but I am thinking of an approach that uses a web of trust to validate peoples identities.  In addition to finding a very rare hash, you would also need to sign the block with your private key.  And that private key would need to have been signed by some number of other private keys to be valid.  The rule would be that no two blocks in a row can be signed by the same private key, or even keys directly adjacent on the web of trust.

I know what I have described is not presented in enough detail to be workable, but I think with a little bit of though engineering we can make it into something workable.

I can already anticipate one critique, which is that such a concept would be too easy to manipulate, or game.  But what is our goal, as a community?  Hint: It is not to bow down and pay respect to the most powerful computer.  Too powerful a collection of computing power would or could game the system.

I get that one appeal of the SHA-256 hashing is that anyone can run the hardware totally independent and support the network with out any sort of authentication.  Perhaps blocks could be allowed that didn't have a private key attached, but then at least the next two blocks would have to be singed.

The web of trust would be maintained in the blockchain itself.  It would have to start somewhere, but I think our community is small enough still that we can get this going.

tl,dr
• Web of trust to supplement SHA-256
• Successive blocks would have to be signed by different private keys
• This idea is not yet fully developed

I agree with your example, but I don't think it addresses my point.  When I said 'function of total hashes performed', I was not referring to the set of hashes that solved blocks and are available for inspection in the blockchain.  I was speaking of all hashes performed on mining equipment thus far.

Lets say that 500 hashes have been performed in the last 3 months, and 500 in 3 years prior.  Every time the hash function is performed, it is equally likely to result in a value below 0x000000000000000000000000000000000000000000000000000000000000000F.  Such a hash would be included in the blockchain unless the difficulty was absurdly high.

Now that you have searched back 11 months, I'll guess that accounts for over 90% of hashes performed thus far.  So I'll give there being a 10% of finding a lower hash if you keep going.  Clearly this won't be proved nor disproved by what you find.

Also, my argument is not based on the particular hash value you found.  If you had found 0x000000000000000000000000000000000000000000000000000000000000000F in the first 90 days, the chances of finding a lower value would of course be essentially zero even if you looked back very far.  Mine is a very general argument.

The chance of finding a lower hash earlier in the blockchain would just be proportional to the area under the hash rate graph.  It is a function of the total number of hashes performed.  So, 50% of all hashes have been performed in the last 90 days, then there would be a 50% chance of finding a lower hash in all previous days had their blocks examined.

And that hash you found was about 1000x 'rarer' than was necessary to be in included.

Well I'll just tack this question on here:  Anyone know what block has the smallest hash, or how small that hash was?

That does happens a lot, but there are plenty of other routes.  Miners and early adopters (who probably mined in the past) maybe be looking to sell lots and lots of coins with minimal records being created, while preserving their anonymity and not dumping the coins on Gox which would have an adverse effect on price.  I wouldn't be surprised if more than 50% of the USD/BTC exchanging was done OTC.

They wouldn't just be sending money to Gox.  That would be the fastest way to raise the price, and they would have every incentive to try to hide the fact they were accumulating BTC.  They would use a bunch of different techniques, starting with the purchase of several million dollars worth of ASIC hardware.  Next they should hit up local bitcoins and buy as many coins there as possible, no worrying about losing 20% to fraud.  That action would affect the Gox price, as some people would be using Gox to hedge and otherwise enable the trades, but that strategy would drive up the price far more slowly than buying the coins directly on Gox.  They may even dump coins on Gox and buy them back OTC.

Should be arriving tomorrow.

Most people.  Cars, boats, clothes, computers, etc.

Well I think we would all like to see them steal at least one satoshi, just to prove that they can.

It's more likely there was a 'collision' in the pseudo-random number generation that bitaddress.org relies on than and actual address collision.  I would guess 1,000,000's of times more likely.  That may even be considered a bug.  I modify every generated private key by hand to guard against such issues.