Yeah, I understand. But keeping such cash at your own home and not in some pre-arranged location away?

Our ex-CFO had a relative who died approximately in 2000, never had SSN (edit: or maybe he had it but never used it as an adult) nor bank account, did all transactions with suitcases of cash. But collecting his estate was a multi-week trip around the country to visit all the places where he stored it (mostly regular safes/storage as well as some hidden caches on his properties).

Edit: I know that e.g. European illegal immigrants to the USA, especially those who don't speak English well, tend to store/deposit their savings also in cash with the neighborhood groceries/restaurants/bars/bodegas/convenience stores. Sort of like Leon: The Professional http://www.imdb.com/title/tt0110413/ . But storing at home?

30k$ at their own home? Wife is a lawyer/paralegal? This is getting interesting.

Anyone care to speculate what would be the use of 30k$ to be kept at home? AFAIK nobody in the family was running a cash-based small business. I know people occasionally keeping much more than that at home, but they are in the cash-intensive business not involving Bitcoins.

Edit: E.g. I used to know a woman real estate agent who used to keep way over 100k$ in small bills very close to herself at all times. Her specialty was buying highly-appreciated (by value) but decrepit (by condition) real estate from alcoholics and other addicts.

What would be the business model requiring to keep 30k$ in cash at home? I don't care if legal or illegal. Please give your guesses.

Edit2: I also remember CFO of some rather large company keeping that amount of cash on hand at all times when his company was involved in lawsuits (not him personally) and the company used to employ many blue-collar workers living paycheck-to-paycheck (or paypacket-to-paypacket).

Thanks for posting this.

Anyway, anyone who was using non-ECC memory for the financial applications was already in the state of sin.

The good thing is that I expect the hardware quality to improve after this exploit becomes widely known. New DDR4LP standard apparently already includes the mitigations/workarounds.

One thing I really liked was intECC DRAM chips: DRAM which is pin-compatible with the current non-ECC DRAMs but internally uses ECC. This will allow many people to preserve most of their hardware investments (mostly laptops) by just replacing the DRAM modules.

1) Install OSX server only on actual server (Mini) computer. Don't install it on portable notebook computers, it severely reduces performance and battery life.
2) With a simple cable modem + Airport Extreme you emphatically don't need a separate firewall, the trivial one already inside the base station is completely sufficient
3) Forget about registering and configuring domains for now, just configure and use "Back To My Mac" service until you have sufficient understanding of public vs. private IP addresses and Network Address Translation and port mapping
4) For now use the OSX server as a normal house computer that is on 24*7, download the server documentation from Apple and skim it (don't read thoroughly). You'll just need to roughly remember what kind of information is available in the Apple references. Many well-meaning advice givers on the forum give complete bullshit information with respect to Apple technologies and you'll need to be able to quickly sanity-check it with the actual references what is true.
5) 1&1 has a proprietary DNS manager web panel that is rather self documenting once you really understand the networking basics in (3) and (4)
6) obtain the actual precise information about your ISP business account settings: is it single IP or block of several consecutive IPs, is it just IPv4 or dual IPv4 & IPv6. Don't post the uncensored details here, don't post your real domain names here, use placeholder names and numerical values. This forum is full of sharks that will own your network as soon as you disclose sufficient information because everyone knows that you are just a beginner setting up your first network.
7) Create a separate thread in Technical Support with a meaningful title e.g. Creating remote-accessible mining farm using Apple technologies. We'll help you more there.

Stay safe, man!

I presume you currently have a cable modem in front of your Apple Airport Extreme. When you move also use a modem for the ISP access. If the new ISP forces you to use a "residential gateway" learn how to configure it to "bridge mode" and continue using Apple-only networking. Avoid "double-NAT" and other hacky configurations, there is a frightening amount of misinformation on various support and discussion boards.

At least you are aware to avoid following misinformation from Windows users.

From the rest of your post I can tell that you don't understand what you are doing with your network. If you keep opening ports the end result will be that the remote hackers will have better control of your network than you.

With your level of knowledge the only way to do it is to keep one Mac permanently at home and configure your Airport to allow only Apple Remote Desktop to your at-home Mac. Alternatively you could use "Get To My Mac" service from Apple.

After that you can buy the Mac OSX Server upgrade from Apple (less than $20) and set up your own VPN and other services that are described in the OSX Server documentation. Reading the OSX Server docs will also help you to learn and understand the networking basics, both general IP and the Apple specifics (like afp:// not aft://).

No matter what you do you will have to have a permanent (or nearly permanent) computer that monitors your home farm over the LAN. If you don't yet have a spare Mac at home than buying a Mac Mini and installing a server upgrade on it is the best way to spend time and money.

Have fun, just don't become another basket case Mac user with home network owned by hackers.

Edit: Ha, ha! Our posts were seconds apart!
Listen to your own internal voice!

Ah, so there is a NAT device involved here. This basically invalidates all your previous observations, as they can be explained easily as the errors in the NAT implementation. Especially if somebody advertises "full cone NAT" (only relevant to UDP) when interfacing TCP application.

Please do us all a favor and tell us the manufacturer/model/version information for your NAT box. Everyone could then just add it to they "do not use/buy" list.

OK, if they don't behave like a normal client behind a NAT that definitely confirms your suspicions. Large scale NAT farms are popping all over the world right now, and many programs tend to go berserk when receiving connections from those.

How about another hypothesis: an head-end of a CG-NAT (http://en.wikipedia.org/wiki/Carrier-grade_NAT) device for some large French MVNO (http://en.wikipedia.org/wiki/Mobile_virtual_network_operator) or some similar arrangement like Orange FunSpot (Free WiFi Internet access service).

IBM PC was not reverse engineered. IBM published very detailed technical reference manual that contained entire schematic of the circuitry as well as full assembly listing of the BIOS. The details of the IBM PC platforms (classic, Jr, XT, AT & PS/2) were never secret.

Please don't mix up reverse engineering with various clean-room design methodologies.

I will however believe that there were people who were paid to pretend to do reverse-engineering and probably some of them were even paid to swear to that under the penalty of perjury or create an "alternative construction" that served as a proof of reverse engineering.

I trust you and I'm not claiming that you are trying to track the users of Trezor. (Plural "you", meaning "your company and associates", not "you personally"). I'm more interested on the possibility of correlation attacks done by somebody else on the users of Trezors, especially those users willing to connect the Trezor to a non-trusted and not-verified computer.

I'll repeat my question:

Is there any publicly available information or speculation about the SoC chips you use that would either exclude or confirm the presence of undocumented storage? IIRC the devices you use support "USB on-the-go" which is a fairly complex protocol. Do you even heard any substantiated rumors about the undocumented features of your chips. I've worked with some much older SoC chips where it turned out that OTPROM and ROM memory was in reality just EEPROM protected against write by convoluted trickery in the software drivers (can't recall the exact manufacturer at this time, later acquired by Rainbow Technologies).

I easily believe that there's nothing in your code that would be designed for tracking. But do I think that NXP doesn't leave something traceable in the device itself? Do they document every bit of the JTAG state? Is there any open, published source that would confirm that their SoC devices aren't traceable?

I'm not sure that memory pools per different policies will be sufficient. Primarily because each pool will have different policy of accepting zero-fee transactions because the fee will be out-of-band.

Pools should start integrating with other businesses like exchanges or casinos, and then each pool will have material incentive to support the integrated business.

So I'm more thinking a memory pool per different peered mining pool, especially because the number of mining pools should go down.

Anyway, for now it is just another way of counting the proverbial chickens before they hatch.

You again start writing with a style and confidence similar to Mircea Popescu. I mean the absolute value is similar and the difference is in the sign/direction.

Quite obviously: transaction propagation (1) and block header propagation (2) are two different things and there's no point to keep conflating the two. The respectable and not underhanded miner will propagate transactions first before propagating the discovered block headers. For the (1) part the average propagation time is in the order of 5 minutes, only in the (2) part every millisecond matters and directly affects the probability of orphans.

I think you are presuming that the miners are still using the legacy network protocol as implemented in the core client. I think it is already obsolete and anyone who mines uses the new "relay network" protocol implemented out-of-process by Matt Corallo.

https://bitcointalk.org/index.php?topic=766190.0

I'm going to assume that your analysis is obsolete purely because for anyone really mining (pools or large farms) the new protocol is the way to go.

And even if the new "relay protocol" isn't going to get included in the core client it is a no-brainer that any large scale progressive-thinking miners should have private connections between themselves, possibly secured with IPsec. Ideally they should have a multicasting backbone established amongst themselves (kinda like NASDAQ extranet), but I'm too cynical to believe that they are technically capable of that.

Go back and read the Microsoft's "Red Balloons" paper. This has been discussed here and elsewhere many times.

"A few years"? More like "a few months" or maybe even "a few weeks". A database with write-ahead-logging is a perfect example of pessimal application for flash storage: lots of small writes, forced buffer flushes to permanent storage and never read back (unless the database application crashed).

http://en.wikipedia.org/wiki/Write-ahead_logging

If "normal thumbdrive" means the typical cheap drive with controller and wear-leveling optimized for FAT32 file system then I wouldn't be surprised if the device died even before the full current blockchain synchronization was complete (when formatted using any modern file system).

Unfortunately the very high write amplification caused by bitcoind will also kill any flash device in a few years.

There's quite bit of work that needs to be done to safely run Bitcoin on a flash device for extended time periods. I'm not aware of any open-source flash-specific database engines.

OK, thanks for the clarification. I believe your observation must be specific to Germany or maybe broader to the Western Europe.

In some Asian communities (both in Asia itself and expatriates in other continents) there is an opposite correlation: poor people tend to spend inordinate amount of time and energy&fuel to elaborately cook their ethnic food, to the detriment of their children who are drafted to help. On the other hand reasonably well-off people tend to use quick-food or self-bagged cold lunches to be able to effectively participate in economy and education.

Are you talking about the legacy peer-to-peer protocol in Bitcoin Core or about the new, sensible implementation from Matt Corallo?

https://bitcointalk.org/index.php?topic=766190.0