DIY Crime? Options

[TommyTwoToes]

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.

[pbangarth]

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

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.

[nezumi]

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.

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.

This completely eliminates the Shadows. All corps would have near Godlike intelligence gathering as every (IMG:style_emoticons/default/nuyen.gif) spent by each runner could be individually tracked through each set of hands it passed through.

Again, not at all (IMG:style_emoticons/default/smile.gif)

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.

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.

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.

[Doc Chase]

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.

[TommyTwoToes]

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 (IMG:style_emoticons/default/nuyen.gif) per transaction.

If someone steals 1million (IMG:style_emoticons/default/nuyen.gif) , you need to go into every corp's system and track the use and current location of each of those million (IMG:style_emoticons/default/nuyen.gif) , out of trillions of (IMG:style_emoticons/default/nuyen.gif) 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.

[Doc Chase]

So the swag is trackable, just not easily so. Sorta like bills now. (IMG:style_emoticons/default/nyahnyah.gif)

[Dwight]

<double post>

[Dwight]

@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.

[Smokeskin]

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 (IMG:style_emoticons/default/nuyen.gif) spent by each runner could be individually tracked through each set of hands it passed through.

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.

[nezumi]

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 (IMG:style_emoticons/default/nuyen.gif) per transaction.

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 1million (IMG:style_emoticons/default/nuyen.gif) , you need to go into every corp's system and track the use and current location of each of those million (IMG:style_emoticons/default/nuyen.gif) , out of trillions of (IMG:style_emoticons/default/nuyen.gif) and perhaps billions of transactions per day.

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.

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.

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.

Further a huge problem with your suggestion is verifying the accuracy of the data going into the database. Who gets to call what stolen?

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.

[pbangarth]

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.

[Doc Chase]

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

[Smokeskin]

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.

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.

[Yerameyahu]

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?

[nezumi]

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.

[pbangarth]

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?

[Dwight]

There is no requirement that you report back.

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).

[Smokeskin]

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?

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.

[nezumi]

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?

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).

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).

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).

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.

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.

[Smokeskin]

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.

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.

[Dwight]

Replace it with four downloads of the binary tree a day and you get basically good-enough time resolution without that cost.

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

[Doc Chase]

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.

Mmmhm! I could see someone trying to recreate Sneakers.

[nezumi]

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

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?

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

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.

[Doc Chase]

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. (IMG:style_emoticons/default/nyahnyah.gif)

[Smokeskin]

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?

Through willing suspension of disbelief (IMG:style_emoticons/default/wink.gif)