December 2003 - cypherpunks-legacy

Barriers to offshore banking
by m＠BlueRose.com 17 Dec '03

17 Dec '03

szabo(a)netcom.netcom.com (Nick Szabo) writes: >The middle class avoids current offshore banking because it >is user-hostile and puts their life savings at high risk. They may be user hostile, but they are not necessarily risky. And the middle class uses offshore banks a great deal. Offshore means any bank outside the US. Swiss banks are quite reliable, though they occasionally provide information to the US government and they withhold taxes on interest earned. Austrian banks are just as reliable and offer not just numbered accounts, but password protected, numbered accounts, and do not tax interest earned. There are many other places with reliable banks that will protect one's privacy. The Channel Islands have a system of government that dates to 1066, numbered bank accounts, and the largest bank on the Islands is the tenth largest bank in the world. >An offshore bank often takes a week or more to service requests for >statements sent by snail-mail. That's why most people use faxes to communicate with offshore banks. I would be surprised if email didn't follow soon. >Offshore banks are notorious for obsconding with customers' money. In a few jurisdictions, this is true. For example all that is required to set up a bank in Grenada is to form a corporation with the word "Bank" in the name. That's it! No regulations at all. Most jurisdictions in which offshore banking take place regulate several different types of banks. Class A banks are the type one finds in the US, with tellers, etc. Class B banks are typically run by a company which sets up the bank and are almost always prohibited from doing any business with the local residents. Class B banks are usually divided into restricted and unrestricted. An unrestricted bank can do business with anyone not a resident of the country in which the bank exists, while a restricted bank can do business only with parties named at the time the bank is formed. Reserve and capitalization requirement vary from country to country but unrestricted banks must nearly always meet tougher requirements than restricted banks, and Class A banks must meet tougher requirements than Class B banks. For example, in the Bahamas, a restricted Class B bank must have a minimum capitalization of $100,000 and pay an annual license fee of $5000. For an unrestricted Class B bank, it is $1,000,000 and $25,000 respectively. I don't have figures available for a Class A bank but they are much higher and the Class A bank would be subject to regulation. >Reputation information on these banks is hard to find to >nonexistant. It's not that hard to find. Many offshore banks are more than 100 years old. >The typical offshore bank customer spends $1,000's on legal fees to >obtain information on reputable banks, the legality of what they are >doing in both the local and offshore jurisdictions, and to set up >obscure, sophisticated legal entities. True but misleading. The typical offshore bank customer spends about $1000 to $2000 to set up a corporation, so that the bank acount is not in his own name. This obviates the requirement to tell the IRS when an American opens a bank account in a foreign country. >There aren't any good statistics, but I'd guess that most of the >money saved by going offshore is lost to legal fees and fraud. If that were true, there wouldn't be offshore banks. The tax savings probably outweigh the legal fees by 10 to 1 or more in most cases, and fraud exists, but is not so rapant that people stay away. M Carling

1 0

INTERNET BANKING
by Sandy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort(a)attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Michael C. Berch raised several issues about digital banking which I would like to address. Though his post was very thoughtful, it had some imbedded common misconceptions. He listed four concerns he had with digital banking--Security, Convenience, Privacy and Credit. He then wrote: No. 1, security, is a problem with anonymized, offshore, network banking. Today we rely on a combination of reputation and regulation . . . But in a *nonregulated* environment, there will have to be private deposit insurance which could easily have some bootstrap problems in building the initial market. [Emphasis added.] For the foreseeable future, all digital banking will be conducted from some national jurisdiction--just as with current offshore banks. Every world jurisdiction has some degree of regulation which is specifically aimed toward client protection. . . . I envision transactions ending up in two big buckets: card services and "cheque" services. . . . The card system, insecure at it is, is fast becoming universal; . . . I find it difficult to imagine large-scale displacement of institutions like VISA, MasterCard, and Amex, simply because they do what they do (provide instant POS credit authorization, guarantee merchants quick payment, etc.) very well. There is no need to displace current institutions. When a credit (or debit) card is issued by a bank in a privacy jurisdiction, all financial information about the card user must, by law, be kept secret. . . . Because of the degree to which strong financial privacy threatens government power (especially taxing power. . .) I can easily imagine that (1) banks doing business in or "touching" the US and most politically similar sovereignties will not be able to prevent themselves from disclosing identity and transaction information about their customers, and (2) people will probably be prohibited from dealing with these banks if they are in fact beyond the reach of legal process. Currently, there exist thousands of banks that offer strong financial privacy. They have little difficulty in preventing disclosure of customer information. Why should a digital bank be any different? No Western countries now prohibit their nationals from dealing with offshore banks. With the advent of strong encryption-mediated communications, anonymous remailers and, of course, digital banking, any such future prohibitions would be nearly impossible to enforce. The last issue Michael raised was credit. He wants a digital bank that will loan him money without knowing who he is. Don't hold your breath on this one. Those who wish to borrow money can probably expect that digital banks will want exactly the same personal and financial information that traditional banks require today. Such is the nature of business. S a n d y >>>>>> Please send e-mail to: ssandfort(a)attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLT7J7E5ULTXct1IzAQG7fgP7Bzuu+wF4ESBy5WIS70BhMllxKDJiwG/e VvJyCyRQH/F590WPnyewUf3sw6GucMjH862iHOaTdlSipB5Iw1RiNYnsj85YYMe6 7UhPw1ajE+vlAyxMD38D+t6zLdHb3wdrn/26TfEnit8PbkLWD6qhCN0f+3WeKZE6 HbixxfTb93M= =2T+9 -----END PGP SIGNATURE-----

1 0

Re: alternative to Fair Cryptosystems
by Carl Ellison 17 Dec '03

17 Dec '03

Someone wrote: >What about us who won't obey? :-) No problem. The Clipper and the Fair Cryptosystem proposal work on voluntary compliance as it is -- so the same people will volunteer for this. It saves all sorts of time and money and hassle doing engineering of chips. It's pure software. As far as I can tell, it's a pure winner! Carl

1 0

postmaster@lance.colostate.edu speaks
by Steve Dempsey 17 Dec '03

17 Dec '03

So far I have replied individually to complaints about the noise coming from L. Detweiler. My response has been, and continues to be, that he has the right to post in public any opinion he may construct. Some of you have begun to conclude that these postings constitute real threats and libel. I have been reluctant to get involved, but these claims of illegal activity force me to respond. Most of the complaints refer to a document recently posted to many public mailing lists via remailer services. This document apparently describes a fictitious contest or game called SQUISH. Individuals named in this document have written to me claiming that L. Detweiler <ld231782(a)lance.colostate.edu> is the author and is responsible for posting it. They also claim it is libelous and threatening. These folks are understandably offended at the references to themselves and to the invasive method of distribution. But the connection to Mr. Detweiler and to the systems I administer is indirect and assumed. I have spoken with Mr. Detwiler and he claims he did not post it. I have seen no evidence that he posted it. His name was not attached to the document in any copy I've seen. It was distributed by remailers that remove the source of the message. If you're going to claim libel, you better be able to prove the source. I've seen no proof; I have seen only finger-pointing. As to the substance of the document, it appears to be a joke. The reference to entry deadline of April 1 should tell you to check your sense of humor before taking it verbatim. As for the other references cited, including Usenet postings from anonymous addresses and mailing list articles delivered by anonymous remailers, I find it difficult to accept these at face value. It's possible that Mr. Detweiler composed these. It's equally possible that someone else did so. There are plenty of copycats on the net and they're not easy to separate or identify. I won't even try to sort out the anonymously posted or remailed data. And here's what you've all been waiting for: Regarding Mr. Detweiler's other activities on the usenet and other public lists, he concedes that his crusade of the past 2+ months has been less than productive. He has agreed to cease the postings that have yielded so few results other than inflammatory debate. I expect the noise to quiet. I expect to receive from users at large no further complaints of disruptive data coming from his account here. Finally, I will announce to everyone who wants to file additional complaints that I do not enjoy playing the part of net.policeman, nor net.complaint-dept; that really is not my job. Unless you can show some direct evidence that one of my users is harassing you or otherwise violating your rights, or breaking some law, I don't want to hear about it. Complaints about anonymous posts and remailed data should go to persons administering those services. ================================================================== Steve Dempsey Engineering Network Services steved(a)longs.lance.colostate.edu Colorado State University root(a)longs.lance.colostate.edu Fort Collins, CO 80523 postmaster(a)longs.lance.colostate.edu +1 303 491 0630 ==================================================================

2 1

Re: faster code for neural network
by Matthew Bernardini 17 Dec '03

17 Dec '03

> >> Recently I received the code for a neural network. It is written in > >> standard ANSI-C. However, running it on the Mac gives me a lot of coffee > >> breaks ( it takes 10 min on a IIci, 3 hrs on an LC ). I was wondering if > >> anybody out there has experience with this and knows of ways to make the > >> code faster ( replacing ANSI routines with Mac-based routines. > >> > >> If you are the woman or man with this experience mail me! I really need the > >> help ( it's all for my master's thesis ). > > > >You might want to get a match coprocessor for the LC. The ci has one, > >and that's probably your problem. (I'm not sure if the LC can take one, > >though!) If my memory still works after the two pints I just had, the LC > >has a 68020 without any FPU. You might want to upgrade to an LC III and > >find out if it has an FPU. I believe neural nets use floats, no? If so > >you will most certainly need and FPU if you want decent speed. > > > > The LC does lack a FPU, but you can get one on a card. I'm not sure if > this would help though, because it would depend if your compilier would > generate FPU code. I know you can with Think. You also might need to take > into account which compiler you are using for this kind of program, there > seems to be a vairation in efficency between Mac Compilers. > > As for using toolbox calls, using Apple's SANE library might help. I > haven't had much experience with it, but it would probably take advatage of > the FPU. > > E-mail me if I can help anymore. (I'll run the program on my Q700 if you > just need a quick speed test.) > ___________________________________________________________________________ > "I want to know God's thoughts...the rest are details." > -- Albert Einstein > _________________________________________ > Ron Davis rondavis(a)datawatch.com > Datawatch, Research Triangle Park, NC (919)549-0711 > > That, or use an AV. If you are adventurous you could use Aplle's Real Time Architecture to offload processing to the 66MHZ DSP processor in the AV series. I know of some examples of ARTA. Matthew Bernardini ----------------------------------------------------------------------------- | Rutgers University Computing Services Matthew Bernardini | Hill Micro/Graphics Center 7804 McCormick | Site-Manager (908) 878-0946 | 017 Hill Center | (908) 932-3129 (908) 932-4921 -----------------------------------------------------------------------------

1 0

Re: AI code speed up !!!!
by Scott Bence 17 Dec '03

17 Dec '03

I don't know what (if) I read this in any books or mags. I would recommend MacTutor(name may have changed) I had read it all through college and worshiped it. You can find it at *the Book Stop* if you know where on is. You can benchmark you routines fairly easy. Before you call your function get the ticks off the clock then again afterwards, then get the difference. ie ... start=GetTicks(); /* I think this was call, check the toolbox */ foobar(); total_time=GetTicks()-start; ... One more thing, I left out another optimization kludge. Try to reduce the number of calls outside your function by moving the code it is calling to inside the function. This reduces the associated overhead of jumping (jsr $xxxx). Also, if you have to go through the "toolbox" check into the function GetTrapAddress(). Do this for Moveto(x,y) and then you can bypass the entry point of the toolbox and go directly to the routine in ROM. This should shave off 5%-15% on the execution of toolbox calls. DO NOT HARD CODE THE ADDRESS IN YOUR PROGRAM! YOUR PROGRAM WILL DIE A HORRIBLE DEATH ON ANY OTHER MODEL! Use GetTrapAddress(). Hope all this helps. Let me know how things work for you. > Bence, > > I saw your list of recommendations for code speed-up on the mac. I'm > currently learning how to program the mac, make tool-box calls, etc. and > I found the list interesting. Is there book of information like that, or > is this just stuff picked up in the trade? Let me know when you get a chance. > > -john. > jdblair(a)nextsrv.cas.muohio.edu > #include <std_disclaimer.h> ---------------------------------------------------------------------- ------ Scott Bence * Texas State Technical College @ Waco, Texas ----- --- Computer Networking & Systems Administration * sbence(a)tstc.edu --- ----------------------------------------------------------------------

1 0

Re: alternative to Fair Cryptosystems
by fb＠cyberg.win.net 17 Dec '03

17 Dec '03

>You can have your surveillance agency (or agencies which need to cooperate) >publish their own RSA keys (big ones, presumably), and all the good little >boys and girls who want to prove how obedient and conformist they are can >include those keys as recipients when they encrypt messages. If there are >to be multiple agencies which have to cooperate, the PGP or RIPEM software >would have to change to split the message key by XOR with ranno pieces, >but in the meantime, you could just include the FBI in your list of recipients >and save everybody the hassle of having to get pieces to put together. > >Simple -- direct -- speaks right to the gov't desire. What could be wrong >with this? And anyone who didn't include a surveillance agency in the list of message recipients would of course be demonstrating that they were up to no good and should be investigated. How diabolically clever. Next let's "voluntarily" switch to postcards for all snail mail. :) --------------------------------------------------------------- Francis Barrett, F.R.C. | Thou canst not travel on the path | The Cybernetics Guild | before thou hast become the Path | fb(a)cyberg.win.net | itself. | ---------------------------------------------------------------

1 0

Re: Internet Banking
by Matthew Bernardini 17 Dec '03

17 Dec '03

> (First of all, I just wanted to say hello, especially to those of you I > met for the first time at the Cypherpunks BOF last night at Usenix.) > > I caught up on the digital banking thread and have a few thoughts > about future banks, financial privacy, and nonregulation issues, > especially how they relate to the way things are done now. > > What is important to me in an ideal bank, in roughly descending order: > > 1. Security. The bank will not disappear, steal my money, allow others > to steal my money, or unwarrantedly cut off my access to it. > > 2. Convenience. I can easily and reliably spend the money I have on deposit, > deposit funds from elsewhere, and communicate with the bank regarding > my accounts. > > 3. Privacy. The bank will not (or, possibly, cannot) reveal details > of my financial situation or transactions to others including the > government. > > 4. Credit. The bank will loan me money for appropriate purposes if > needed (and my credit rating is acceptable). > > The financial institutions I currently deal with do a pretty good job > of all of these except (3), which is not their fault but is the > government's. (Except for crud like banks that use trivial keys like > your SSN for access to banking by phone.) > > No. 1, security, is a problem with anonymized, offshore, network > banking. Today we rely on a combination of reputation and regulation > to provide bank security -- the banks we deal with stress size, > longevity, permanence, etc., in their marketing campaigns, and there > are mandatory reserve requirements and mandatory deposit insurance. > Reputation should translate pretty well in our idealized banking world > -- what is better than the electronic word of mouth of the Internet? > But in a nonregulated environment, there will have to be private > deposit insurance which could easily have some bootstrap problems in > building the initial market. > > Convenience, #2, should be a vast improvement. Freed from the > necessity and cost of maintaining a network of impressive physical > edifices of Federal-style architecture, and coupled with more-or-less > ubiquitous networking and computing, banks can concentrate on giving > ultra-fast, efficient transaction services via authenticated e-mail > and customer services via a Web-like server. > > I envision transactions ending up in two big buckets: card services > and "cheque" services. Cards are for when you are wandering around, > and e-mail "cheques" are for paying regular bills. The card system, > insecure at it is, is fast becoming universal; I stopped carrying a > checkbook around years ago and use credit cards for all possible > transactions: you get a comprehensive statement at the end of the month with > the names of all your vendors, and you also get a nice premium for > using their transaction services (mine is airline frequent-flyer miles). > In any future banking system one must assume that card-based > transaction service will be the main, if not only, means of > casual transaction, and it will be up to us to to build in the > ncessary privacy and authenticating schemes to make this a trustable > system. I find it difficult to imagine large-scale displacement of > institutions like VISA, MasterCard, and Amex, simply because they do > what they do (provide instant POS credit authorization, guarantee > merchants quick payment, etc.) very well. > > While e-mail "cheques" are attractive because the mail infrastructure > is almost entirely there already, I wonder if they will ever become more > than a small percentage of total transactions, possibly limited to > pre-authorized direct drafts for such things as utility bills, and > maybe mail orders and transactions between individuals. > > #3, privacy, is a very difficult issue because of the regulatory role > of the government. Because of the degree to which strong financial > privacy threatens government power (especially taxing power; see > previous messages on this) I can easily imagine that (1) banks doing > business in or "touching" the US and most politically similar > sovereignties will not be able to prevent themselves from disclosing > identity and transaction information about their customers, and (2) > people will probably be prohibited from dealing with these banks if > they are in fact beyond the reach of legal process. > > This leads to the key question: should one trust (i.e., disclose > one's identity to) or not trust one's bank? It would certainly be nice > to be able to trust your bank, as it makes things much easier for all > parties. They would be able to freely grant you credit (#4 above), > since you could verifiably prove your assets, real property, > employment, etc. But if you trust your bank, then they may be forced > to disclose your identity to the government under legal process. Thus > it is probably best to postulate a banking system that does not > require trust. > > This complicates #4, credit. I can envision a system of vouched-for > indirection (not unlike signing PGP-keys) that would allow you (the > borrower) to disclose assets/earning capacity to a trusted third party > that would certify to a lender that you (known to the lender only as a > numbered account) are credit-worthy. If it can be made possible > to break the traceability link between the credit-vouching agency and > the lender, privacy may be possible. One problem may be that > credit-vouching agencies cannot easily be "offshore", since they may > need to examine your real estate (or whatever) though this could be > done, perhaps, by appraisers or other local agents. > > Comments? > > -- > Michael C. Berch > mcb(a)net.bio.net / mcb(a)postmodern.com / mcb(a)remarque.berkeley.edu > > I am new to this list, so excuse me if this topic has already been discussed, but I think you need to take a 200 level course in economics called Money and Banking. I think the idea is so obsessed with tax-evasion and privacy protection that you have ignored all the economic consequences of the ideas you are proposing. 1) Who will insure your money ? Can you trust anyone but the US gov't to back your funds ? Even in the S&L scandal the gov't refunded money to people that weren't insured by the FDIC. Do you think they would come to the cypher-punk rescue if your money up and flew to Brazil ? 2) A doctoral thesis could be written about this one, but what about the Federal Reserve ? You would wreak havoc on interest rates, inflation, international balance of payments, and international trade. How would this electronic bank adjust for inflation or an expanding/shrinking electronic money supply ? Take a look at some historical texts that describe the problems that the Early American Revolutionaries had in breaking from the British Currency. It took several failed efforts, and the currency of the United States has been constatnly evolving ever since. 3) Interest Rates and Inflation ... 4) Interest Rates and Inflation .... 5) You guessed it, Interest Rates and Inflation. What about Capital Markets ? What about foreign labor unit exchanges? Is mexican labor worth as much as US labor? I think there are more economic issues than encryption issues to be considered in this case. Matt ----------------------------------------------------------------------------- | Rutgers University Computing Services Matthew Bernardini | Hill Micro/Graphics Center 7804 McCormick | Site-Manager (908) 878-0946 | 017 Hill Center | (908) 932-3129 (908) 932-4921 -----------------------------------------------------------------------------

2 1

Off-Shore Banking
by DECLAN＠delphi.com 17 Dec '03

17 Dec '03

Complete guides to off-shore banking, and more, are available from LOW PROFILE newsletter POBox 84910 Phoenizx, Arizona 85701 Tel 1-800-528-0559 Fax 602-943-2363 I subscribe to this newsletter and find the information well-researched and worthwhile. If a banking institution has a bad reputation, they publish the information. Lots of other information on asset ptrotection at home and abroad. declan(a)delphi.com

1 0

RE: RSA is weak link
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > ...the IDEA encryption algorithm used in PGP is actually > MUCH stronger than RSA given the same key length. Even with a 1024 bit > RSA key, it is believed that IDEA encryption is still stronger, and, > since a chain is no stronger than it's weakest link, it is believed that > RSA is actually the weakest part of the RSA - IDEA approach. >Confirmation? True; it is more expensive to do a brute force search over the IDEA keyspace than it is to factor a 1024 bit number using the best known factoring algorithm :) I did some calculations once and I think the crossover point is between 1500 and 1600 bits, at which point factoring becomes more difficult than searching. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLUA1OoOA7OpLWtYzAQGjwwQAwhDqTc6TKZqEjfO1xbC1llasfVfOL3wM 72ofDeWtw7vtdxFb98iLShomdwr12G6I+7qbHwzKyLM5+r/T/DzNRAW2e+MD894Y DNAZazRz2YLuiGpr0LBSC1S6EyFbtcuwoPh1U5LORyUrEo4YCJsYYoFfcnN+Vb8B ddv28VkktBs= =irY2 -----END PGP SIGNATURE-----

1 0