This is something I've been considering for my players but I was wondering if others had tried this and had any advice.

We've hit somewhat of a lull in the storyline and our team is a little stretched for resources at the moment so I had considered basically letting them come up with a heist or crime themselves to make money and then I construct an on-the-spot run based around that. Essentially, a quick non-Johnson initiated operation.

Has anyone tried this kind of spontaneous style run before?

Sure. Player-directed runs can be great fun, but you have to stay on your toes as the GM. You'll never know what they'll come up with. Also, make sure their objective isn't too far reaching. If they decide their characters can make more money doing the side work, they might loose interest in returning to your original story line.

Hey, when the jobs Mr. Johnson has for you dry up, you can always go back to stealing Ford Americars.

I feel like player-instigated runs are what inevitably happens during legwork and planning. If the team decides they need X gear, etc.

I've always wanted to do this . I recommend reading the original book of "The Taking of Pelham 123" and also "The Great Train Robbery".

Both are somewhat dated (TGTR more than TTOP123) but still have some nice ideas about what might go into planning and executing a crime. Films are less useful IMO since the planning and legwork required is generally not exciting enough for Hollywood...

This sort of thing works best if they have a deadline and/or very solid motivation. If they merely drift into it out of boredom they will have little incentive to raise the excite-o-meter and pull off something flashy.

How strapped are they for cash? Do they have any old financial debts that can suddenly be called in?

***

Alternatively, if they are rather flush at the moment, let them get caught up in somebody elses crime. Maybe your temporarily well-off runners decide to spend a night at the casino or dog-track only to find themselves right there when a robbery goes hideously wrong - and the end up in a hostage situation, with the players mixed up inside a crowd of moderately (or very) wealthy hostages. Can they extricate themselves before the SWAT teams turn up? Will the gear they have inevitably smuggled in with them get noticed, or can they use it to take out the hostage-takers? If they save the day, do they stick around for fame and rewards or do they slink away into the shadows?

I always kind of hope my PCs who are perpetually hard up for cash will try and alleviate their problems by knocking over a stuffer shank or even making a plan and robbing a bank.

They never do.

What you might consider doing is inundating your players with stuff to do. Create bounty screamsheets for your players to go hunt down, have their Fixer send a mass email stating that so-and-so is offering a reward for hellhound carcasses, one of the runner's ex girlfriends called and needs help, tell your players you're going to start assessing stress-based penalties if their players don't go the hell out and do something fun, then have trouble follow them everywhere.

My point is this: try to give them some structure instead of letting them call the shots.

Robbery and smuggling are the two big ones my group falling back on. We'll hit a place in Seattle and take the loot to Portland, LA, or where ever to sell. Also when we get an out of town job we put out feelers to see if one of our contacts has something that needs to go in the same direction.

Vice and the other crime books have ideas that you could bring up or your players could try. Hackers and TMs can always to whatever the hell it is they do, Sams and other muscle types can do strong arm stuff, and Mages and Shaman have all sorts of magical mischief they can get into. It's basically limited to the imagination of your group.

Depends a LOT on your players. I would *LOVE* to see a long con run by players, but I've never seen it done before. Most players say "I want to work this sort of job. What's in the classifieds?" and that's as far as they'll go.

With great luck actually. One of my favorite campaigns to this day was when several PC's decided to usurp their Yakuza connection, and take over their block, and the surrounding neighborhood. The PC's worked hard to not only subvert his connections, and people, but they set him up-add in the assorted commitments of running a neighborhood, and protecting themselves from incursions, crooked cops, rivals, etc...

I'd love to run a campaign where the group is trying to set up something like the ShadowSkool.

but how do you rob a bank in matrix wireless society!? what do you steal? account codes?

I'm hammering out the details for a gang-level game (starting out gang level anyway, planning on the PCs eventually being world-tier movers & shakers), and the idea I have for DIY crime is that they can support themselves in a Low lifestyle if they spend all their downtime pursuing gang-related criminal activities.

They do the "hard" missions -- the stuff we play out during a session -- in order to buy free time in which they can train up their skills, or to get extra cash for 'wares, or for whatever else they want to better themselves.

If the bank in question is Zurich Orbital...you don't.

I like the idea, can be fun.

People still have to make physical deposits of Cash. Money and Corporate Script still exist.

And, of course, there are always Gold Reserves, as well as stockpiles of other easily tradeable goods.

Oh, and Safety Deposit Boxes. I think we just talked about those not so long ago.

The bank manager.

"Let's go steal us a bank manager." Ahh, Leverage. Although, more likely it'd be, "Let's go steal us a bank." Didn't that happen once?

What HAVEN'T they stolen in Leverage?

If I recall correctly, the largest successful IRL heist ever revolved around kidnapping a bank manager and his family and holding them until he paid out large sums of cash.

The problem with EFT is that it makes it possibly to simply 'undo' the crime. If corporation A can prove malfeasance, in theory the bank the funds were sent to would, voluntarily or by force, send those funds back or, at minimum, deny them to the crooks. Even if you stored the money in Bank of Fakistan, who refuses to comply with corporate orders, if you stole enough of it, the corporate script/nuyen from the bank will be backtraced or marked and unusable outside of Fakistan.

Ultimately what it comes down to is either:
a) nuyen is created because the banks say so. They require little, if any support to issue new money. If this is the case, they have a license to print money and the only corporations permitted to have that much power will be the big ones who will crush shadowrunners if it becomes clear they're mucking about.

b) nuyen is trackable, because it's all eletronic funds and somehow 'created' by a centralized authority. Each nuyen is uniquely identified from its sisters, and because it's electronic, this identification can be tested in a trivial amount of time. All nuyen stolen is immediately blacklisted as such, and becomes worthless.


What you need to keep the cash is a long enough window to launder the money while it's still legal tender. That means either any bank robberies need to be pulled off such that they don't appear to be a robbery until well after the crime, or that you need to con people out of the money and make sure the person who willingly handed over the cash doesn't realize the mistake until well after the exchange, if ever.

I'm of the opinion that bank jobs are more in the realm of hackers, lawyers, politicians and con men (which of those items does not belong?) than it is of stick-up men.

Emphasis mine..

This requires nearly infinite data storage and processing power. Think about it, you would be storing the serial number for every bill (and by extension every coin), and tracking every time it changes hands. This storage would need to be done simultaneously in every Bank (not every branch, just in each corp), and updated realtime. Tracking the movement of blocks of money, sure, we do that now. but tracking each buck seperately is beyond the pale.

This completely eliminates the Shadows. All corps would have near Godlike intelligence gathering as every spent by each runner could be individually tracked through each set of hands it passed through.

Much like an assumption that every square meter of the Earth is under constant, real time, satelite surveilance, this kind of omnicience makes the game unplayable as anything other than a law abiding corp citizen.

Mmm. 1984: The RPG.

Roll BOD to be crushed under the bootheels of the Party.

Roll Initiative to determine who can volunteer to be crushed the fastest, they are the winner

Have any of your players watched Drugstore Cowboy before? Hopefully yes.

Anyway, do the players have specific equipment in mind? I suggest that you encourage them to go after equipment rather than actual cash. Again, Drugstore Cowboy. They aren't doing it for cash they are doing it gear. That keeps it far more personal, far less likely for the players to "overreach" (due to greed) and blow up the campaign.

Really, just have the players use their contacts to look for specific gear. Then go from there.

A Party official is approaching. Roll for Oppression.

I made my roll.
I walk up to the Party offcial with for 977j-286665b and ask for his signature.

In an electronic, mostly cashless society, these would still be viable targets for theft. People will still have all kinds of material goods stored away: jewelry, gold, bonds, Swiss bank account numbers, maps to buried treasure, ID, passports, cash in various currencies, blackmail evidence, drugs... the list goes on.

Not at all.

First, let's assume there are 1 trillion nuyen. Each nuyen takes say 10 bytes of storage space to store its super-long, encrypted serial code. That makes 10 terabytes. Right now, that would probably cost you on the order of... $400? $600? You're transferring 10 nuyen. That's 100 bytes. Let's say you have to send it twice for a handshake. That's still not even a kilobyte.



Again, not at all

Everything is cost vs. benefits. The cost of implementing a system like this is significant, but the cost of letting people produce money at a whim is even more significant. So clearly we need SOME sort of authentication system in place. This one is one of the simplest - every nuyen has some sort of encrypted data which verifies it's valid. You decrypt it and get the private signature and there you go - an electronic stamp. The signature may be by a government (nuyen), a corporation (corporate script), or even by a private individual or smaller organization (chuck-e-cheese tokens).

To lock-down money, or take it out of circulation, you send a message to the central distributing authority, who verifies this request is valid, modifies the public-facing inventory information, and trickles it down to vendors saying 'nuyen serial code 11102-10234-231ba is not valid and will not be honored'. Each one takes 10 bytes of memory, so if there's 1b in dirty cash, that's 10 gigs. Store it in a binary tree and it's a few thousand quick checks per nuyen, so a 1 giga-flops can check a thousand nuyen in one second (that's probably a 2060 pocket calculator).

Now if you steal 20 nuyen from some guy, the amount of time and work it will take for him to verify his identity, the fact of the crime, transmit it up to his local bank, who transmits up to the division bank, up to the central authority, acquires approval, sends it down and refreshes with all local vendors will be far more than it will take you to cash that in for a bunch of aztek-cola ('drink the pyramid!') If you didn't pay with your SIN, what do they have then? Grainy video footage? Whooo! And of course, if I am paying you for illegal behavior and neither of us reports it, it'll never be locked down at all. This, of course, is why runners always change over their cash from the sticks they're paid with to a secure bank or two, though. It might be clear for now, but tomorrow it might not be. Once you've washed the cred anonymously through a few banks or other institutions, what you have to use is safe and the trail is plenty muddied (they'd need a lot of warrants to get the Bank of Fakinistan to cooperate with Renraku Mutual). It's unlikely the cost of the legal work will be worth the value of catching the guy who has already blown it to change his identity and home address.

However, if you steal $10b, you better believe that who you stole it from already has the ear of that central authority, and they will be on the phone with them before you've left the building.



There's a very major difference between having information and understanding it. Considering the Earth right now is almost entirely under real-time satellite surveillance, it doesn't seem a big problem. For most people, it becomes a Library of Babel problem.

I liked Aztek-Cola's previous slogans:

"Sacrifice your thirst!"
"Bathe in the power of refreshment!"

And if we can assume 10 TB per trillion nuyen - okay, that's not terribly bad. Still may take a while to find the one code string for the nuyens amongst the trillion they've got going.

Except that McDonalds needs to track that, and every bank, and Burger King, and Wal Mart, and so does every other little corp. Not only that, but even thougn the same "bill" might pass through their corp multiple times, it needs to be tracked each time. Its 10 TB per trillion per transaction.

If someone steals 1million , you need to go into every corp's system and track the use and current location of each of those million , out of trillions of and perhaps billions of transactions per day.

The total transactions per day in that digital economy might be higher than the number of queries that your system can complete in a day.

So the swag is trackable, just not easily so. Sorta like bills now.

<double post>

@nezumi

You are talking about a situation where the cash is effectively a fixed value credstick. This requirement to check back (AKA report back) to a central database (even when it's somewhat distributed it still represents a centralized repository) for each transaction effectively defeats the purpose of the script.

I understand that the concept of physical script cash has a big problem in the age very cheap, accurate nano manufacturing. But having serial numbers that require checking back isn't going to fix the issue. There has to exist that sweet spot where some authority can mass manufacture, and distribute, what are in essence IOUs for [significantly] less than their face value but the cost to counterfeit the IOU is close enough to the face value that it isn't profitable for someone to do it.

Further a huge problem with your suggestion is verifying the accuracy of the data going into the database. Who gets to call what stolen? As you shrink that list to make the data reliable you decrease the coverage of the system. Once you have huge sums of cash spending most it's lifespan off the system's grid you've got enough liquidity to support sizable robberies, even right out of the system and reported, and spending it off the grid in the shadow economy.

Near infinite storage? What? You haven't even done a ballpark calculation on what it would take I guess.

It could EASILY be done. Let us make it something ridiculously large, like 80 bit serial numbers for nuyens. That's 10 bytes per nuyen.

Say I want to move 1 million nuyen. That's a 10 megabyte. 10 megabyte today is nothing. And that's a million nuyen. Very few will see even a tenth of that moving through their accounts per year. That's less than a megabyte in serial numbers. Say accounts are identified with a 64 bit number and a 32 bit timestamp, complete transaction logs with time, sender and receiver per nuyen takes triple that, that's 3 megabyte of data per person per year. Your typical business has an income of say 3-4 times the average wage per employee, and some financial transactions could be many times that, but the bottom line is, even at 100 or 1,000 times storage needed per person, it isn't even close to a problem regarding storage, even if each and every nuyen was tracked.

Another comparison, say the entire Iraq war cost a trillion dollars so far, every transaction of every dollar fully logged would take no more than 30 terabytes under such a scheme.

Not at all - at least not any more than they currently have to track paper currency. They have two choices -
1) They store the nuyen data on their home server.
2) They send the nuyen data to the bank to store.

If they do the former, what they're doing is storing say 10,000 10-byte encrypted serial numbers. They can then do whatever they want with those serial numbers, just like they would with normal cash. This is like normal certified credsticks.

If they do the latter, they're connecting to the bank and saying "we are transferring this information to our account". The bank verifies all of the signatures, then 'deletes' them (or however you want to manage that) and changes the value in McDonald's bank account.

They don't need a database listing all of the serial numbers of all of the different pieces of nuyen. Each nuyen would have a serial code that fits into a certain format, and has a little segment that never changes. So for example, let's say this is the 512,493rd nuyen issued. The serial code may be 000512493 (issuing number) 1111 (fixed code). This is encrypted with the bank's private key. The public key is available to everyone. McDonald's decrypts the nuyen with the public key, verifies all of the data computes (the number is within parameters and it ends with 1111), and saves the encrypted information as the currency. (The public key is public, and lets you verify nuyen is legitimate. Imagine it like those pens that check for fraudulent cash. It would take a trivial amount of space to store and use, and you don't strictly need it - but it's free, so why not. The decrypted data is like the serial code of a dollar bill. It's worthless, except as a form of verification or tracking. The encrypted data is worth something because the fact it's encrypted prove it's backed by a bank. And the private key is worth a TON, because if you have that, you can make your own money.)



If someone steals 1m nuyen, you would send out a memo with 1,000,000 10-byte serial codes.

When McDonald's gets your transaction, or at 2pm when it runs the daily virus check, it decrypts each nuyen not sent to the bank and does a quick check against a binary tree to see if that nuyen's serial code matches one on the 'do not use' list. If it does, McDonald's can say 'someone used this at 2pm to buy a burger. Here's the video footage. Here's the SIN (if used)', send a claim to insurance for the difference, and that's about it.

The time for a business to check this is trivial, like I showed earlier. We're talking about 5 seconds, at most, using the worst available hardware. May as well complain about virus scanners. And this whole setup is less computer-intensive than the credit card system we're using right now.

Of course, this system is really only going to be used for certified cred. Most normal transfers will be just like using your credit card or check card - vendor contacts bank with your information, requesting X amount of money. Bank verifies the funds are available and sends them to the vendor's bank. Vendor's bank verifies receipt. But if you're talking about robbing banks, you're not exactly going to be sending it to your First Union credit card, are you? And any credit card company or bank who regularly accepts known illegal transfers is probably not going to be doing a lot of business. So by virtue of talking about robbing banks, we're moving to certified cred.



There is no requirement that you report back. I'm not sure where you got that from. If I have a credstick reader, I can verify that your nuyen is (or was) genuine by decrypting with the public key and checking the fixed part of the serial code (in my example, 1111). Once I have the public key, I can do this without ever connecting to a server anywhere. *HOWEVER*, this obviously means I'll never be tying it into my bank account, and we can reasonably assume that most vendors would want to do that.

Would black economies use this? They sure could, but I don't know that there's any real advantage to it. It involves trusting the banks, it may not have favorable exchange rates (if lots of vendors require SINs and your stuff is mostly black market), etc. If you take the Mafia's currency, you may get a discount on goods, you show local support, whatever. In black market communities like you're talking about, local currencies are fairly common, so I'd expect the same thing here.



The issuing authority. It's all their money. If Renraku determines that your Renraku corp script isn't valid, that's their decision. The books aren't clear about who operates nuyen, but obviously someone needs to print the stuff. So most likely they have a trans-national organization similar to the federal reserve in the U.S. This single entity would be the issuing organization for nuyen, and would be responsible for saying if nuyen already in circulation is valid or not. Major banks may have the ability to issue nuyen (because of leverage banking), but it would be an administrative pain to have a few thousand organizations all arguing about monetary policy, so there must be one central authority to handle this stuff. Can the big banks freeze funds? Don't know. If so, appeals would likely go back to the federal reserve. Certainly though, a bank would be able to contact the Feds very quickly to get those funds frozen, if it so desired.

Even if the storage required is not an issue, and I am not convinced by the arguments so far that it isn't, the larger issue mentioned already is the effort required to maintain the audit trail, similar to evidence tracking in a police investigation. If you do not keep track of every transaction with each nuyen, you lose control over that nuyen. The transfer of billions of nuyen daily, many of which will go through many steps from start to end, will bog down any tracking system.

The issuing authority of the nuyen is Geimenschaft Orbital - which I believe was reiterated in Corp Guide. I'll check later.

How can you not be convinced? Check the numbers. How large do nuyen serial numbers have to be, account number of sender and receiver, a time stamp - that's what you need per moved nuyen, times the number of nuyens moved person. That ends up in very little data per person.

It is doable by today's standards. Watch a single viral video in your mailbox and you've transferred more data than your entire audit trail for a year would take. And we're talking 2074. There isn't a storage issue, there isn't a tracking issue.

Why exactly does each Nuyen have to be tracked, though? The vast majority of the US Dollar economy is electronic, and it certainly doesn't involve tracking each dollar. It's just credits and debits. Are we just talking about anti-counterfeiting here?

The why depends on which method you're talking about. EFT/CC/Debit Card, it's the tracking that's actually doing the paying. My bank calls your bank, they send all the relevant data, and agree my account goes down by X and yours goes up by X. No tracking, no transaction.

By the second method (the one I wrote about up there which, based on previous discussions here, is the one I personally beleive is used for certified cred), tracking isn't necessary. There is no step that requires you go back to the central bank and say "I got X amount from person Y". *HOWEVER*, the cost of reporting it is trivial, so the question shifts from 'why' to 'why not'.

Frankly, no matter how you cut it, I think the question of 'why not' will still come up. We're talking about electronic funds. EVERY unit of electronic currency *must be* capable of authentication, otherwise counterfeiting is trivial. It is *most likely* capable of proving its uniqueness, simply because when all you're moving is bits around, from a security standpoint, it's easier to prevent counterfeit via simple copying of those bits by making each set of bits unique so it can be tested. I honestly cannot think of a simpler method of creating currency tokens than this.

So if every currency token can be both authenticated as being genuine and as being unique, and it's all already in a standardized electronic format, very quickly we find that the question ceases to be 'why would Weapons World bother verifying this is valid currency' to 'why would Weapons World NOT verify it is valid'. The cost of verification is trivial, and the cost of not verifying it is non-trivial (your currency may be counterfeit). Considering in the real world many locations spend a non-trivial amount of time verifying currency is real by using anti-fraud pens, UV lights and so on, I have to imagine that the idea of doing this for absolutely no cost in time or money would mean it's fairly universal among legitimate (i.e. SINned) vendors. So at this point, tracking is not a requirement, but it's an attractive free service. (Imagine for a moment if every dollar bill in the till were automatically loaded in a database with its serial number - do you really think Wal-Mart wouldn't save this information somewhere or compare it or data mine it? The only cost now is that the data would have to be input manually. But electronic funds, almost by definition, do not suffer that drawback.)

Of course though, since tracking is strictly voluntary, this won't always be the case. And I can think of several methods that runners can get around these methods, if the GM cares to enforce it. Most likely, all of the underworld outfits have money laundering as a side business, and compete with each other on rates, keeping the cut low. 10-20% seems perfectly reasonable to visit a Yak or Mafia bookie to turn your certified cred so it's untraceable.

I guess the part I'm not understanding is this: Say firm ABC gets a nuyen labelled 10101100. How is this verified as being a legitimate nuyen, and not a copy, except by looking in every repository everywhere for another instance of nuyen 10101100?

Asking "Is bill A444BCD106 stolen?" carries the implicit information that you are about to be in the possession of bill A444BCD106. Any vender that is NOT doing this is a potential dumping point for stolen currency (AKA currency that was truly issued and passes all validity checks unless you check back with the central database that keeps track of which is stolen and which is not).

ZO has Bank A listed as the location of the nuyen. Bank A has you listed as the owner. You want to pay someone using Bank B. You tell your bank to transfer the nuyen to the seller's account. Bank A tells ZO to change location of the nuyen to bank B, bank B registers this and the seller as the new owner, and informs the seller that the nuyen is in his account.

You need to be able to spoof or fake the communication between ZO and a bank to cheat the system.

Good question, and to go into it, I need to take a moment to talk about Public Key Cryptography. (You can skip ahead if you already understand public key cryptography.)

Public key cryptography relies heavily on the concept that some mathematical operations work very easily one way, but are extremely difficult to reverse. For instance, mod, or remainder. 5 mod 2 is 1 (easy!) but how do you figure out X mod Y = 1 for x and y? Now that's extremely difficult, especially when we're talking about giant numbers. So you can imagine the process of public key cryptography as being made up of keys, or Xs (variables) being plugged into effectively black box, irreversible equations to get new numbers.

The person sending the message has a private key, basically a giant, prime number. Only he knows it. He plugs the original message and his private key into the encrypting equation to make an encrypted message. Every private key also has a mated public key. If you plug the encrypted message and the public key into the decryption equation, you get the original message back. The two keys are mated - they only work in conjunction with the second key - but having the public key doesn't help you figure out the private key at all, so the private key is always secret.

So if you're sending out private messages, you can share your public key with all the recipients. Of course, this means your messages are only as private as your public keys. If everyone has your public key, your encrypted messages aren't secret any more - anyone can decrypt them. However, it has a second benefit. Since no one but you has your private key, and because keys are uniquely paired, that means that no one can falsify your encrypted messages. If you take an encrypted message and decrypt it with my public key, that means you *know* it was encrypted with my private key, and if my private key is kept very safe, that means you also *know* that it was me who encrypted it. This is called a digital signature.

Now the question becomes, 'how do I know that what I'm getting out is a sensible encrypted message'. That's a lot easier - you just make part of the unencrypted message static - identical in all messages. My example was '1111', although most likely it would be longer. This really is a message saying "I am a 1 nuyen note".

Because of the huge numbers we're talking about, it would be almost impossible (i.e. - 'heat death of the universe before you solve this equation') to create a private key/message pairing such that, using your public key, you would get that same tail.

So what is the process?

0) The bank generates a private and public key. The private key is carefully guarded, the public key is distributed to whoever wants it (via a secure method). Vendors download the public key and install it into whatever they're using to store encrypted nuyen token messages.

1) Bank makes an actual computer note, including whatever they want. If we go off of our current currency, it includes a serial number, location created, author, year created, that it is a note of currency, and it's value (also, a pyramid with an eyeball). We can play with this though, making it longer or shorter. There's also no reason to use decimal, since that's a bit wasteful, so likely a lot of this information is stored in hex instead (so you'd have the letters A-F included in your numbers). Part of this information changes from token to token, and part of it always stays the same.

2) The bank encrypts it with their private key, and probably encapsulates it in something useful (saying 'this is 1 nuyen').

3) The bank distributes the encrypted note to whoever wants it.

4) People using the encrypted notes exchange them like they would normal bills.

5) Vendors who wish to verify their currency decrypt the nuyen message using the public key. They look for the static '1111'. If they don't get '1111', it means either their decryption program or public key isn't correct (unlikely), or this isn't a genuine note (more likely). They can accept the note or not, as they wish - it's just a string of bits.

6) Vendors may, if they wish, report this information back up to the central banks. This secures and pools their money. At this point, they also report that this serial code was paid on this date.

The only big flaw in this plan is that an individual may copy that nuyen note, like putting a bill in a photocopier. This is a concern whenever you're using a decentralized electronic token system - no matter how you cut it, you're just shifting bits around, and bits can be copied. I can see two solutions to this -
a) Regular reporting. Fix the problem of decentralization by centralizing it. Vendors probably do this anyway, because centralization is fun!
b) Physical controls. The public key may not be just available for anyone to download. It may be encapsulated and hardcoded inside of a device, sold for more than it's worth. This is your credstick and credstick reader. If you control the hardware and make it very difficult to fool with, you greatly reduce the odds of tampering with it to the point of being able to copy data like that.

Of course, this would all be wrapped up with extreme penalties and fines for tampering, so a vendor won't do it just because it is so likely to be traced back to them (you don't poop where you eat and all that).





Sending data up and down like that is time-consuming for no good reason. That's server-side processing for a basic data search. It's only real advantage is that it's up-to-the-second. Replace it with four downloads of the binary tree a day and you get basically good-enough time resolution without that cost.

(In practical terms, it's the difference between 1,000 1-second queries over the day, or a single 5-second query.) So because of size and time constraints, I imagine this information is downloaded daily and just processed locally.

The exception of course would be if you're accepting a million-nuyen transaction. Just like no bank is going to accept 5,000 twenties without doing some checking, they won't accept 1m in certified cred without double checking it. But this is why robbing a bank carries different concerns than stealing a wallet (and always has).




This is a traditional EFT, and indeed, spoofing the bank would be the only real solution. However, I'm still very wary of it. It's an extremely tight, well-tracked process with a big, fat electronic trail. I'm not aware of any successful attempts to simply steal money by electronically impersonating a bank, so I don't know that it's possible. It would be quite a heist.

Only in SR4, P = NP and doing the reverse operation is really easy.

That part of it, I just pretend not to think about. With no crypto you don't have reliable identity verification, and any sort of electronic financial system seem to be completely unfeasible to me.

OK, really what you were talking about is terabytes of data per currency per vender.

Mmmhm! I could see someone trying to recreate Sneakers.

Wait, what?? That's just... but then... But how do you encrypt anything ever?? How do you have a dependable matrix if everything can be decrypted with minimal work?




Yes, each type of currency requires its own multi-terrabyte data file, although the size will vary based on its popularity (if there are only 1b Renraku dollars in circulation, you'll have fewer 'dirty serials' than with 1t nuyen). This is assuming that every type of currency is the same format, just signed with a different key, and that all of them use this method to control currency flow. Of course, the vendor has the option of accepting (or not) any particular currency, just like IRL. I imagine most places only accept nuyen plus one or two corporate scripts. In the CAS, nuyen and CAS dollars is probably pretty common. So we're still, at most, dealing with petabytes, and there's no serious loss of processing speed per transaction - there's only a single additional check (type of currency). I imagine this whole process would be wrapped into the reading device, just like credit card readers right now. We have 4-6 major credit card companies, each with their own infrastructure and so on, but it's clearly not a huge hassle for vendors.

Clearly you haven't seen the bill for access to those systems.

Through willing suspension of disbelief