Subject: Re: Small/Secure Payment Business Models
From: Steve Schear <[email-masked]>
To: Ronald Duncan <[email-masked]>
Cc: [email-masked]
Date: Mon, 31 Dec 2001 20:55:12 -0800
List-Id: <ietf-trade.lists.elistx.com>

At 05:45 PM 12/31/2001 +0000, Ronald Duncan wrote:
>What is the secret of success?

Politically: having enough juice to buy off Congress and get regulations 
favoring/protecting your turf.  Regulations always favor the regulated.

Operationally: immediate settlement with extremely low direct costs, 
non-repudiation, an efficient automation interface, bi-directionality 
[fostering an active, competitive exchange market], combined with zero 
credit or liquidity risk.

>Why have beenz and others failed?

They weren't real currencies. Flooz was an online gift certificate scheme, 
and Beenz was a shopping incentive scheme. Didn't matter how many times 
Beenz said they were a "web currency" for the sake of the business plan and 
the marketing, they were still just incentive points.

Beenz and Flooze (Digital Based Currencies) failed, in part, because they 
are not a direct money for goods or money for service. The net seems to 
support systems that are deflationary and peer to peer. So middle men tend 
to get squeezed out.  Is Paypal next?

Payment systems must be very careful regarding the 'hardness' , or ability 
to repudiate, the payments accepted to fund them.  Flooz's immediate 
demise  was linked to a credit card scam ring, but the underlying cause was 
a failure to observe good payment risk management.

                                                         Scale of Monetary 
Hardness

Hardness          Item
1                  Street cash, US dollars
(Hard)
2                  Street cash, euro currencies, japan
3                  e-gold
4                  Street cash, other regions
5                  Interbank transfers of various sorts (wires etc), bank 
checks
6                  personal checks
7                  Consumer-level electronic account transfers (eg bPay)
8                  Business-account-level retail transfer systems
(Soft)
9                  Paypal and similar 'new money' entities, Beenz
10                Credit cards
(Ridiculously soft)

Observe that say stock brokerages definitely do not accept credit cards or 
Paypal to fund an account. They will only accept instruments that are very 
hard, such as wire transfers or certified bank checks. When hard money is 
required, only money-types with a hardness of about 5 or better will do the 
job. Observe though that even money order and bank wires can and have been 
reversed.

>What is a Virtual Currency?

What is a real currency?  The existence of fiat paper?

>Convertibility - When to you cross over and get into the money laundering
>regs?

Whenever you deal in an open value system and regulators find you have been 
doing business with someone they consider a criminal or a pariah.  It often 
doesn't matter if they were so considered when you were dealing with them 
or that there was little likelihood you could have determined they were 
engaged in what then or later was consider criminal.

The term 'money laundering' used to mean proceeds from a criminal 
enterprise, but over the past few decades it has come to mean any attempt 
to interfere with a government's interest, Constitutional or not, in 
enforcing financial transparency.  Being accused of being a money launder 
has become the modern day equivalent of being called a Communist in the 
McCarthy era.

>Why small, what about the billon dollar barters?

What about them?  Why not?

>How do you get the liquidity?

Don't allow credit.  Prevent repudiation.

>Go for it!
>
>I am certainly very interested in all of these topics and how to roll out
>our currency and other services.
>
>Regards -- Ronald
>
>-----Original Message-----
>From: Steve Schear [mailto:[email-masked]]
>Sent: 31 December 2001 17:13
>To: Ronald Duncan; [email-masked]
>Cc: [email-masked]
>Subject: Re: Guys Please stop
>
>
>At 12:33 PM 12/31/2001 +0000, Ronald Duncan wrote:
> >It has been interesting, but it is getting a little out of hand.
> >
> >Please flame each other in private.
>
>Sorry if the exchange appeared to be a bit too private.  I saw it as an
>opportunity to discuss some of the underlying, but not often discussed,
>issues surrounding small payment business models.  I think most on this
>list, including myself, want to see a thousand payment system flowers
>bloom.  We live in interesting times.  The legal, market and technical
>landscape underlying payment systems is in great flux.  Many approaches
>have been suggest or tried and its only by understanding what
>considerations drove the decisions of others that we can learn from one
>another and improve chances for future success.
>
>steve

Date: Mon, 31 Dec 2001 13:29:52 -0700
From: [email-masked]
Subject: Re: Small/Secure Payment Business Models
To: Ronald Duncan <[email-masked]>
Cc: [email-masked], Ronald Duncan <[email-masked]>, 'Steve Schear' <[email-masked]>

note that current gift & stored value cards found in large percentage of
the larger retail store check-out counters ... provide a very inexpensive &
succesful "online" small payment model. They currently use magstripe cards
and operate within the same point-of-sale infrastructure as debit & credit.

Date: Mon, 31 Dec 2001 12:51:44 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Guys Please stop
To: Steve Schear <[email-masked]>
Cc: Ronald Duncan <[email-masked]>, [email-masked], [email-masked]

uh, more than one outbreak of ragweed. fine. an implementation, better still,
two, that could, by some stretch of the imagination, interoperate, and might
do so sooner/better/faster in the presence of a specification, would be the
next step in an ietf wg.

there is the drm tf over on the irtf-side of the house as well, but lo-cal
advocacy is no more welcome there.

Content-return: allowed
Date: Mon, 31 Dec 2001 17:45:00 +0000
From: Ronald Duncan <[email-masked]>
Subject: Small/Secure Payment Business Models
To: 'Steve Schear' <[email-masked]>, Ronald Duncan <[email-masked]>
Cc: [email-masked]

What is the secret of success?

Why have beenz and others failed?

e.g. Why did Paribas fail with key line?

What is a Virtual Currency?

Convertibility - When to you cross over and get into the money laundering
regs?

Why small, what about the billon dollar barters?

How do you get the liquidity?

Go for it!

I am certainly very interested in all of these topics and how to roll out
our currency and other services.

Regards -- Ronald

-----Original Message-----
From: Steve Schear [mailto:[email-masked]]
Sent: 31 December 2001 17:13
To: Ronald Duncan; [email-masked]
Cc: [email-masked]
Subject: Re: Guys Please stop

At 12:33 PM 12/31/2001 +0000, Ronald Duncan wrote:
>It has been interesting, but it is getting a little out of hand.
>
>Please flame each other in private.

Sorry if the exchange appeared to be a bit too private.  I saw it as an 
opportunity to discuss some of the underlying, but not often discussed, 
issues surrounding small payment business models.  I think most on this 
list, including myself, want to see a thousand payment system flowers 
bloom.  We live in interesting times.  The legal, market and technical 
landscape underlying payment systems is in great flux.  Many approaches 
have been suggest or tried and its only by understanding what 
considerations drove the decisions of others that we can learn from one 
another and improve chances for future success.

steve

Date: Mon, 31 Dec 2001 09:13:28 -0800
From: Steve Schear <[email-masked]>
Subject: Re: Guys Please stop
To: Ronald Duncan <[email-masked]>, [email-masked]
Cc: [email-masked]

At 12:33 PM 12/31/2001 +0000, Ronald Duncan wrote:
>It has been interesting, but it is getting a little out of hand.
>
>Please flame each other in private.

Sorry if the exchange appeared to be a bit too private.  I saw it as an 
opportunity to discuss some of the underlying, but not often discussed, 
issues surrounding small payment business models.  I think most on this 
list, including myself, want to see a thousand payment system flowers 
bloom.  We live in interesting times.  The legal, market and technical 
landscape underlying payment systems is in great flux.  Many approaches 
have been suggest or tried and its only by understanding what 
considerations drove the decisions of others that we can learn from one 
another and improve chances for future success.

steve

Content-return: allowed
Date: Mon, 31 Dec 2001 12:33:45 +0000
From: Ronald Duncan <[email-masked]>
Subject: Guys Please stop
To: 'Steve Schear' <[email-masked]>, [email-masked]
Cc: [email-masked]

It has been interesting, but it is getting a little out of hand.

Please flame each other in private.

Regards -- Ronald

-----Original Message-----
From: Steve Schear [mailto:[email-masked]]
Sent: 31 December 2001 03:23
To: [email-masked]
Cc: [email-masked]
Subject: Re: The Privacy/Untraceability Sweet Spot (was Re: An idea for
sustainablefile sharing.)

At 08:56 PM 12/30/2001 +1100, Michael H. Voase wrote:
>Steve Schear wrote:
> >
> > Your comments indicate you know virtually nothing about Mojo Nation and
> > what they are/were trying to do.  I understand you are enamored with
your
> > idea but its sloppy and intellectually dishonest to demote the ideas and
> > substantial labors of another without a thorough examination and 
> consideration.
> >
>
>         You are correct, that was extremely rude of me. My upmost and
>sincere appologies. I will endeavour to be more diligent in future when
>researching topics. I will also CC this to the trade WG. Thanks for
>pointing this out.
>
> > Mojo Nation was/is an open source development project.  All client SW
and
> > the system's underlying protocols are pretty well documented in both
design
> > papers and the source code.  Only the mint, its keys and a small amount
of
> > other simple server software has not been openly distributed.  Its only
a
> > relatively small project to recreate the mint and other server (tracker)
> > software and launch your own Mojo-based service using the source.
> >
>
>         Again, my sincere appologies, both to the list and the
>MojoNation project. I didnt realise they had moved to
>Source Forge, or the fact that it is an open source project that is
>near reaching 1.0 status.
>
>         However, now that I have had an opportunity to obtain and
>reveiw the source, there are a few issues with the system that would
>open it to possible fraudulent use, and serveral basic principals
>it is built upon are fundamentally flawed.
>
>         First of all, the concept of a 'micropayment' is vacuous.
>The fact of the matter is that a transaction is a transaction
>and a payment is a payment be it large or small. Without a foundation
>in clearly defining what a 'micropayment' is, the system is open to
>ambiguity. This alone would fail if it were to be tested in a court of
>law.

I think not.  Most countries, including the U.S., differentiate closed 
value systems (e.g., token systems in amusement parks) and those operated 
as open systems whose value is exchangeable for external values.  In 
general, closed systems are unregulated from a banking perspective.

> > There was/is no reason Mojo (the currency) can/could not be applied
within
> > other SW constructs.  It made sense to keep the application of Mojo
within
> > Mojo Nation as the Evil Genius' resources were too small to support the
> > creation and maintenance of an open exchange system for other services.
> >
>
>         True, there is no reason why 'mojos' can't be exchanged. However,
>who would want to? Without a firm basis in cold hard currency, why would
>anyone want to trade upon it.

>Where is the accountability? Where is
>transparency? What is the exchange rate? Who sets the exchange rate?
>Is it free of insider trading?

Even assuming one can convince most potential users that nothing "funny" is 
going on, in the end its all based on reputation.  The "reputation of the 
dollar" is related to my belief, and the belief of billions of others 
around the planet, that for whatever reason a piece of paper with the right 
markings on it will in fact be accepted by billions of others, by millions 
of small banks and moneychangers, and even by the U.S. Government. And the 
related belief that loans, IOUs, promissory notes, bonds, and numerous 
other instruments denominated in these "dollars" will very likely be 
accepted or exchanged, blah blah, by millions or billions of other actors.

Thus, what is the "reputation of the dollar"? Is it because of foolproof 
anti-forgery measures? Is it because of the laws of the U.S.? Etc.?

No, it is a kind of collective hallucination.

>         Also, the details of the transactions involved are
>somewhat murky. Trying to directly track hardware usage is excessive
>in a situation where provision of such hardware and bandwidth is
>provided by the user, and may be fundamentally provided
>as a direct result of other activities.
>That decision belongs to the user, and is based on the hardware
>and service available to their equipment. The fact that they are
>willing now to do it for free indicates that the expense involved
>is not excessive. Otherwise, they would not do it at all.
>
>         No rather that trying to concoct some artificial
>interpretation for what the real equipment and support costs,
>hand over a part of the transaction and let the user decide
>if it is worth their while or not. As technology moves forward,
>the associated costs of transactions will decrease over time
>and the provision of payment can be decremented until a reasonable
>balance between cost of deployment and return on investment is
>achieved.

This was taken into consideration early in Mojo's plans.

>         These factors cannot be determined fully until a real
>world test of the system is done before bringing it online.

It is never possible to fully determine everything in any new venture.  If 
I understand your objection then no venture would ever launch.

> > Infrastructure (including back office and fraud prevention) fixed and
when
> > the numbers are worked through it becomes obvious to most biz dev types
> > that they don't add up.  The reason Mojo was based on system resources
is
> > that it eliminated much of the risk and settlement costs.  The focus on
the
> > "millicent ghetto" for ecash value systems with external convertibility
is,
> > I believe, a fatal mistake of almost all e-payment services.
> >
>
>         Well, you admit it yourself here sir, a fatal mistake.

The Mojo was never externally convertible.  The mistake was never made.

>         I agree whole heartedly, except with a few points.
>
>         Back office resources and fraud prevention should be provided
>by the payment service which should exist as a trusted entity that
>can be held accountable for its actions.

Tell that to the holders of Beenz and Flooz.

>Liability to
>the payment service should be limited to the value of the transfer.
>The responsibility of the payment service is to provide the wire
>protocols and back end servers needed to collect double entry
>accounting records. With the provision of this infrastructe factored
>into the transaction cost, a sustainable model of record keeping
>can be established.

Not in the case of most millicent systems.  When such factors are included 
the costs can exceed 20 or more percent of the transaction value.  For 
example, e-gold (which advertises transaction costs of 1% or $0.50 which 
ever is less) charges a whopping 40% when cost are of very low value.

> > By failing to acknowledge the "high-value" markets for untraceability,
> > characterized by such things as Swiss bank accounts
> > and income-hiding, porn-trading rings, and information markets, the
whole
> > technology of privacy/untraceability gets ghettoized into low-value
markets
> > like "untraceable subway tokens" (wow, gee!), weak versions of proxy
> > surfing tools, and boring attempts to get people to use digital money
for
> > things they don't mind using Visa and PayPal for.
>
>         Umm, most of these 'high-value' markets are just the same as
>the 'low' value markets. A payment is a payment, If the price is high
>then so be it. The copyright holder and their content must compete
>with all other available content on a level playing field.

Ahh, but when cost models are worked out in detail it often becomes quickly 
evident that low cost transactions are a money loser.

>         However, some of these so-called 'high valued' transfers
>could be characterised criminal activity. Considering much of what
>would make the content so valuable that it is in the exceptionally
>high price range, usually falls into the class of illegal or contraband
>information. For example, selling millitary or corporate secrets
>is obviously illegal, and attempts to sell such content over the
>payment service would be prohibited. In such cases it would be the
>responsibility of the international body running the service (probably
>either the world bank or a special commission of the United Nations)
>to detemine wether the content was appropriate for distribution.
>The content would also have to be the property of the individual
>or company wishing to deploy that content across the network.
>Stolen company secrets are not the property of the theives, thus
>would be barred, and turned over to the authorities.

You obviously don't understand the concept of digital bearer certificates 
and anonymity.

>         Also a clear definition of what characterises a sale over
>the service would need attention. Content which is sold over the
>service is a sale, not a license agreement. The purchase of goods
>over such a service must be limited actual sales, where the native
>rights of the reciever are respected. Attempting to attach special
>conditions of sale should be rejected by the network. There are
>existing payment methods that adequately deal with this type of
>transfer, and as such, content of this manner should be redirected
>to that service. Content of this type would include items such as
>licensing source code from a commercial software supplier would
>fall under this model, along with expensive software packages.

Your business model appears based on assumptions of a relatively static 
balance of market power between copyright holders, publishers and 
consumers.  This is think is a fatal flaw.  You should consider that the 
present copyright situation may be little different from the situation 
faced by the church upon the invention of moveable type presses.  Other 
than the accelerated pace of change the result is likely to be quite
similar.

>         However, as to the rest of your rant (for wont of a better
>word), you seem to have drifted off the topic of a public payment
>service into the shifty realms of corporate criminals, assasins
>and peadophiles. In regard to these comments, all I can say is
>that the appropriateness of materials for general distribution
>must be rated by relevant rating authorities. All liability and
>responsibility of obtaining censorship rating rests with the
>copyright holder (as it does now in the classical model).

The classical model is about to end.  See Lessig's "Code is Law".

>         Lastly, as for people wanting to use 'untracable accounts'
>would be in for a nasty shock. The payment service must publish
>all sales publicly for ratings information, sans the identities of
>the purchasers. Also published will be the ratings information of
>people supplying content, and the top software suppliers. Beside
>making the system accountable, it also provides essential tool
>for users wishing to decide who is the best software supplier and
>content supplier for their needs. So if the authorities needed
>to investigate the accounts of people _receiving_ money over the
>network, they wouldnt even need a warrant, just a search over
>the ratings website should do. However, the actual names of
>individuals will be withheld, rather using account titles instead.
>Upon reciept of a warrant from law enforment officials, the
>account name of the individual or company would be made available.

I doubt the millions fo people who are now getting much of their 
entertainment for free via P2P are at all interested in telling anyone 
anything significant about their meat space identity or using any millicent 
payment schemes.  Have you used any of these services?  Do you know what's 
happening?

steve

Date: Sun, 30 Dec 2001 19:22:45 -0800
From: Steve Schear <[email-masked]>
Subject: Re: The Privacy/Untraceability Sweet Spot (was Re: An idea for sustainablefile sharing.)
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>

At 08:56 PM 12/30/2001 +1100, Michael H. Voase wrote:
>Steve Schear wrote:
> >
> > Your comments indicate you know virtually nothing about Mojo Nation and
> > what they are/were trying to do.  I understand you are enamored with your
> > idea but its sloppy and intellectually dishonest to demote the ideas and
> > substantial labors of another without a thorough examination and 
> consideration.
> >
>
>         You are correct, that was extremely rude of me. My upmost and
>sincere appologies. I will endeavour to be more diligent in future when
>researching topics. I will also CC this to the trade WG. Thanks for
>pointing this out.
>
> > Mojo Nation was/is an open source development project.  All client SW and
> > the system's underlying protocols are pretty well documented in both design
> > papers and the source code.  Only the mint, its keys and a small amount of
> > other simple server software has not been openly distributed.  Its only a
> > relatively small project to recreate the mint and other server (tracker)
> > software and launch your own Mojo-based service using the source.
> >
>
>         Again, my sincere appologies, both to the list and the
>MojoNation project. I didnt realise they had moved to
>Source Forge, or the fact that it is an open source project that is
>near reaching 1.0 status.
>
>         However, now that I have had an opportunity to obtain and
>reveiw the source, there are a few issues with the system that would
>open it to possible fraudulent use, and serveral basic principals
>it is built upon are fundamentally flawed.
>
>         First of all, the concept of a 'micropayment' is vacuous.
>The fact of the matter is that a transaction is a transaction
>and a payment is a payment be it large or small. Without a foundation
>in clearly defining what a 'micropayment' is, the system is open to
>ambiguity. This alone would fail if it were to be tested in a court of
>law.

I think not.  Most countries, including the U.S., differentiate closed 
value systems (e.g., token systems in amusement parks) and those operated 
as open systems whose value is exchangeable for external values.  In 
general, closed systems are unregulated from a banking perspective.

> > There was/is no reason Mojo (the currency) can/could not be applied within
> > other SW constructs.  It made sense to keep the application of Mojo within
> > Mojo Nation as the Evil Genius' resources were too small to support the
> > creation and maintenance of an open exchange system for other services.
> >
>
>         True, there is no reason why 'mojos' can't be exchanged. However,
>who would want to? Without a firm basis in cold hard currency, why would
>anyone want to trade upon it.

>Where is the accountability? Where is
>transparency? What is the exchange rate? Who sets the exchange rate?
>Is it free of insider trading?

Even assuming one can convince most potential users that nothing "funny" is 
going on, in the end its all based on reputation.  The "reputation of the 
dollar" is related to my belief, and the belief of billions of others 
around the planet, that for whatever reason a piece of paper with the right 
markings on it will in fact be accepted by billions of others, by millions 
of small banks and moneychangers, and even by the U.S. Government. And the 
related belief that loans, IOUs, promissory notes, bonds, and numerous 
other instruments denominated in these "dollars" will very likely be 
accepted or exchanged, blah blah, by millions or billions of other actors.

Thus, what is the "reputation of the dollar"? Is it because of foolproof 
anti-forgery measures? Is it because of the laws of the U.S.? Etc.?

No, it is a kind of collective hallucination.

>         Also, the details of the transactions involved are
>somewhat murky. Trying to directly track hardware usage is excessive
>in a situation where provision of such hardware and bandwidth is
>provided by the user, and may be fundamentally provided
>as a direct result of other activities.
>That decision belongs to the user, and is based on the hardware
>and service available to their equipment. The fact that they are
>willing now to do it for free indicates that the expense involved
>is not excessive. Otherwise, they would not do it at all.
>
>         No rather that trying to concoct some artificial
>interpretation for what the real equipment and support costs,
>hand over a part of the transaction and let the user decide
>if it is worth their while or not. As technology moves forward,
>the associated costs of transactions will decrease over time
>and the provision of payment can be decremented until a reasonable
>balance between cost of deployment and return on investment is
>achieved.

This was taken into consideration early in Mojo's plans.

>         These factors cannot be determined fully until a real
>world test of the system is done before bringing it online.

It is never possible to fully determine everything in any new venture.  If 
I understand your objection then no venture would ever launch.

> > Infrastructure (including back office and fraud prevention) fixed and when
> > the numbers are worked through it becomes obvious to most biz dev types
> > that they don't add up.  The reason Mojo was based on system resources is
> > that it eliminated much of the risk and settlement costs.  The focus on the
> > "millicent ghetto" for ecash value systems with external convertibility is,
> > I believe, a fatal mistake of almost all e-payment services.
> >
>
>         Well, you admit it yourself here sir, a fatal mistake.

The Mojo was never externally convertible.  The mistake was never made.

>         I agree whole heartedly, except with a few points.
>
>         Back office resources and fraud prevention should be provided
>by the payment service which should exist as a trusted entity that
>can be held accountable for its actions.

Tell that to the holders of Beenz and Flooz.

>Liability to
>the payment service should be limited to the value of the transfer.
>The responsibility of the payment service is to provide the wire
>protocols and back end servers needed to collect double entry
>accounting records. With the provision of this infrastructe factored
>into the transaction cost, a sustainable model of record keeping
>can be established.

Not in the case of most millicent systems.  When such factors are included 
the costs can exceed 20 or more percent of the transaction value.  For 
example, e-gold (which advertises transaction costs of 1% or $0.50 which 
ever is less) charges a whopping 40% when cost are of very low value.

> > By failing to acknowledge the "high-value" markets for untraceability,
> > characterized by such things as Swiss bank accounts
> > and income-hiding, porn-trading rings, and information markets, the whole
> > technology of privacy/untraceability gets ghettoized into low-value markets
> > like "untraceable subway tokens" (wow, gee!), weak versions of proxy
> > surfing tools, and boring attempts to get people to use digital money for
> > things they don't mind using Visa and PayPal for.
>
>         Umm, most of these 'high-value' markets are just the same as
>the 'low' value markets. A payment is a payment, If the price is high
>then so be it. The copyright holder and their content must compete
>with all other available content on a level playing field.

Ahh, but when cost models are worked out in detail it often becomes quickly 
evident that low cost transactions are a money loser.

>         However, some of these so-called 'high valued' transfers
>could be characterised criminal activity. Considering much of what
>would make the content so valuable that it is in the exceptionally
>high price range, usually falls into the class of illegal or contraband
>information. For example, selling millitary or corporate secrets
>is obviously illegal, and attempts to sell such content over the
>payment service would be prohibited. In such cases it would be the
>responsibility of the international body running the service (probably
>either the world bank or a special commission of the United Nations)
>to detemine wether the content was appropriate for distribution.
>The content would also have to be the property of the individual
>or company wishing to deploy that content across the network.
>Stolen company secrets are not the property of the theives, thus
>would be barred, and turned over to the authorities.

You obviously don't understand the concept of digital bearer certificates 
and anonymity.

>         Also a clear definition of what characterises a sale over
>the service would need attention. Content which is sold over the
>service is a sale, not a license agreement. The purchase of goods
>over such a service must be limited actual sales, where the native
>rights of the reciever are respected. Attempting to attach special
>conditions of sale should be rejected by the network. There are
>existing payment methods that adequately deal with this type of
>transfer, and as such, content of this manner should be redirected
>to that service. Content of this type would include items such as
>licensing source code from a commercial software supplier would
>fall under this model, along with expensive software packages.

Your business model appears based on assumptions of a relatively static 
balance of market power between copyright holders, publishers and 
consumers.  This is think is a fatal flaw.  You should consider that the 
present copyright situation may be little different from the situation 
faced by the church upon the invention of moveable type presses.  Other 
than the accelerated pace of change the result is likely to be quite similar.

>         However, as to the rest of your rant (for wont of a better
>word), you seem to have drifted off the topic of a public payment
>service into the shifty realms of corporate criminals, assasins
>and peadophiles. In regard to these comments, all I can say is
>that the appropriateness of materials for general distribution
>must be rated by relevant rating authorities. All liability and
>responsibility of obtaining censorship rating rests with the
>copyright holder (as it does now in the classical model).

The classical model is about to end.  See Lessig's "Code is Law".

>         Lastly, as for people wanting to use 'untracable accounts'
>would be in for a nasty shock. The payment service must publish
>all sales publicly for ratings information, sans the identities of
>the purchasers. Also published will be the ratings information of
>people supplying content, and the top software suppliers. Beside
>making the system accountable, it also provides essential tool
>for users wishing to decide who is the best software supplier and
>content supplier for their needs. So if the authorities needed
>to investigate the accounts of people _receiving_ money over the
>network, they wouldnt even need a warrant, just a search over
>the ratings website should do. However, the actual names of
>individuals will be withheld, rather using account titles instead.
>Upon reciept of a warrant from law enforment officials, the
>account name of the individual or company would be made available.

I doubt the millions fo people who are now getting much of their 
entertainment for free via P2P are at all interested in telling anyone 
anything significant about their meat space identity or using any millicent 
payment schemes.  Have you used any of these services?  Do you know what's 
happening?

steve

Date: Sun, 30 Dec 2001 20:55:13 +1100
From: "Michael H. Voase" <[email-masked]>
Subject: Re: An idea for sustainable file sharing.
Sender: [email-masked]
To: "[email-masked]" <[email-masked]>
Reply-to: [email-masked]
Organization: Castle Industries P/L

Greetings,

	I would like to formally retract the following message
below reguarding the MojoNation project and my ignorance of its
continued existence. Their original web site, http://www.mojonation.net
does seem to be down. However, they can be found at: 

	http://sourceforge.net/projects/mojonation

	Many thanks to Steve Schear for pointing out my error.

	I would like to offer my sincere appologies to any and all
people who may have been mislead by my inaccurate statements.
The project has not been discontinued, despite my assertion that
it had. I would also like to add that it is nearing its first
stable release, and seems to be progressing quite actively.

	I would also like to correct my assertion that the project is
closed. It is not, and is available for download at the above address.

	Lastly, I would like to correct my assertion that my concept
was novel due to its openness. This is not true. MojoNation is open,
however, I must clarify that the millenipay system, as proposed, will
use a real currency, not a 'mojo' or any other form of pseudo-currency
for payments. The millenipay system is not a 'micropayment' like
mojonation, just a plain old payment system. There are also some
fundamental structural differences, but I will address those in a
later message.

	Again, my most humble appologies for the misrepresentation of
these facts.

Kind Regards,
Michael H. Voase.

"Michael H. Voase" wrote:
> 
> Eastlake III Donald-LDE008 wrote:
> >
> > Hi Michael,
> >
> > While I don't want to be too strict unless discussion gets out of hand, the politics of  national laws regulating intellectual property and discussion of business models, such as who pay who what %, are really beyond the scope of the IETF.
> >
> 
>         Understood. The inclusion of % figures is mostly for
> illustration and to get the idea across. Considering your response,
> I seem to have transferred most of the idea, but you have missed
> something.
> 
> > A protocol to handle payments for multiparty file sharing might be within the scope of the IETF although its not one of the current goals of the TRADE WG.
> >
> 
>         Understood. However, considering that this concept is a form
> of trade across the internet, I thought that the idea may be relevant
> to your WG.
> 
> > I believe there already exist file sharing systems or proposals for file sharing systems which do provide for the flavor of payment you suggest.  Check out MojoNation http://www.mojonation.net/
> 
>         Ahh yes, I remember MojoNation now. Not the same MojoNation
> that doesn't exist anymore?? There is one problem with
> the MojoNation paradigm. Like any software company, they wanted their
> monopoly on the system. That's the way software companies think.
> Thus they were the software provider AND the paymaster. This fell to
> one side because there was no openness and accountability. The software
> was not open, the protocol they used to talk to their back ends was
> not open. Thus software providers such as napster could not compete
> on the level playing field. MojoNation wanted it all, and for everything
> else to go away. That is why people did not trust it, and as such why
> they
> did not use it.
> 
>         That what makes this system different to MojoNation. It is
> intended to be a _level_ playing field that ALL software providers
> can compete fairly in, including Open Source projects. For example,
> if the Apache group wrote a payment aware module, then they could
> register their software with the payment service and start receiving
> payments for people using their software. From there, they would
> start pulling in their 2.5% cut on transactions.
> 
>         The idea behind MilleniPay is that it is inclusive, rather
> than exclusive. My ultimate goal is to outline an Open  protocol
> specification that software providers can then use to make their
> applications payment aware. The protocol spec will apply to:
> 
> 1) communications between the client software and the payment service.
> 2) communications between the server software and the payment service.
> 
>         The protocol used between the server and the client will
> be dependent on the software in use with one small caveat. There
> would need to be some addition information sent from the client
> to the server, but this can be done in a protocol dependent
> manner. For example, in the case of the HTTP protocol, a couple
> of additional header fields would need to be sent, but its nothing
> the protocol couldn't handle already.
> 
>         Anyways, that what makes MilleniPay novel. Its Openness.
> 
> Cheers Mik.

Date: Fri, 28 Dec 2001 19:55:47 -0800
From: Steve Schear <[email-masked]>
Subject: The Privacy/Untraceability Sweet Spot (was Re: An idea for sustainable file sharing.)
To: [email-masked], Eastlake III Donald-LDE008 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

At 12:46 PM 12/28/2001 +1100, Michael H. Voase wrote:
> > I believe there already exist file sharing systems or proposals for 
> file sharing systems which do provide for the flavor of payment you 
> suggest.  Check out MojoNation http://www.mojonation.net/
>
>         Ahh yes, I remember MojoNation now. Not the same MojoNation
>that doesn't exist anymore?? There is one problem with
>the MojoNation paradigm. Like any software company, they wanted their
>monopoly on the system. That's the way software companies think.
>Thus they were the software provider AND the paymaster. This fell to
>one side because there was no openness and accountability. The software
>was not open, the protocol they used to talk to their back ends was
>not open. Thus software providers such as napster could not compete
>on the level playing field. MojoNation wanted it all, and for everything
>else to go away. That is why people did not trust it, and as such why
>they
>did not use it.

Your comments indicate you know virtually nothing about Mojo Nation and 
what they are/were trying to do.  I understand you are enamored with your 
idea but its sloppy and intellectually dishonest to demote the ideas and 
substantial labors of another without a thorough examination and consideration.

Mojo Nation was/is an open source development project.  All client SW and 
the system's underlying protocols are pretty well documented in both design 
papers and the source code.  Only the mint, its keys and a small amount of 
other simple server software has not been openly distributed.  Its only a 
relatively small project to recreate the mint and other server (tracker) 
software and launch your own Mojo-based service using the source.

There was/is no reason Mojo (the currency) can/could not be applied within 
other SW constructs.  It made sense to keep the application of Mojo within 
Mojo Nation as the Evil Genius' resources were too small to support the 
creation and maintenance of an open exchange system for other services.

>         That what makes this system different to MojoNation. It is
>intended to be a _level_ playing field that ALL software providers
>can compete fairly in, including Open Source projects. For example,
>if the Apache group wrote a payment aware module, then they could
>register their software with the payment service and start receiving
>payments for people using their software. From there, they would
>start pulling in their 2.5% cut on transactions.
>
>         The idea behind MilleniPay is that it is inclusive, rather
>than exclusive. My ultimate goal is to outline an Open  protocol
>specification that software providers can then use to make their
>applications payment aware. The protocol spec will apply to:

Infrastructure (including back office and fraud prevention) fixed and when 
the numbers are worked through it becomes obvious to most biz dev types 
that they don't add up.  The reason Mojo was based on system resources is 
that it eliminated much of the risk and settlement costs.  The focus on the 
"millicent ghetto" for ecash value systems with external convertibility is, 
I believe, a fatal mistake of almost all e-payment services.

By failing to acknowledge the "high-value" markets for untraceability, 
characterized by such things as Swiss bank accounts
and income-hiding, porn-trading rings, and information markets, the whole 
technology of privacy/untraceability gets ghettoized into low-value markets 
like "untraceable subway tokens" (wow, gee!), weak versions of proxy 
surfing tools, and boring attempts to get people to use digital money for 
things they don't mind using Visa and PayPal for.

Plot "Value of Being Untraceable in a Transaction" on the X-axis. This is 
the perceived _value_ of being untraceable or private. Start with "little 
or nothing," proceed to "about a dollar" then to "hundreds of dollars" then 
to "thousands" then to "tens of thousands and more." (The value of being 
untraceable is also the cost of getting caught: getting caught plotting the 
overthrow of the Crown Prince of Abu Fukyou, being outed by a corporation 
in a lawsuit, being audited by the IRS and them finding evaded taxes, 
having the cops find a cache of snuff films on your hard disk, and so on.)

Some examples: People will demonstrably get on planes and fly to the Cayman 
Islands to open bank accounts offering them untraceability (of a certain 
kind). It is demonstrably worth it to them to pay thousands, even tens of 
thousands, of dollars to set up shell accounts, dummy corporations, Swiss 
bank accounts, etc. For whatever various and sundry reasons. (They may be 
Panamanian dictators, they may be Get Rich Quick scamsters, they may be 
spies within the FBI or CIA.) They expect a
"value of untraceability" to be high, in the tens or hundreds of 
thousands...or even much higher. Even their lives. Call this the "Over 
$100K" regime.

I cite this because it disputes directly the popular slogans: "People won't 
pay anything for privacy or untraceability." (In fact, people pay quite 
large sums for privacy and untraceability. Ask Hollywood or corporate 
bigshots what they pay not to be traced.)

People will also pay money not to be traceable in gambling situations. They 
gamble with bookies, they fly to offshore gambling havens, and so on. The 
_value_ to them is high, but not at the level above. If they're caught, 
they face tax evasion charges, maybe. Call this the "$1K-10K" \regime. (The 
spread is wide, from low-rent bookie bets which even the
IRS probably doesn't care much about to schemes to avoid large amounts of tax.)

At lesser levels, some choose to pay cash for their video tape rentals 
(with deposits arranged) just to avoid leaving a paper trail. (Bet Justice 
Thomas wishes he had.)

And then at very low levels there are the cases where the benefits of 
untraceability are worth little or nothing to most people. I call this the 
"millicent ghetto." Actually, the ghetto begins down at around a dollar or 
less. Sadly, a huge number of the proposed "untraceable digital cash" 
systems are targeted at uses deep down in this ghetto.

(Perhaps because they have no hint of illegality?)

On the Y-axis. Plot here the _costs_ of achieving untraceability for these 
levels of achieved. This is the cost of tools, of using the tools, of 
delays caused by the tools, etc. For example, flying to the Cayman Islands 
to personally open a bank account may cost a couple of days in time, the 
airfare, and (more nebulously) the possible cost of having one's photograph 
taken for future use upon boarding that plan for Switzerland or the Caymans.

Lesser costs, but still costs, would be the costs of using Freedom (much 
frustration, say most of my friends who have tried to use it), the costs of 
getting a Mark Twain Bank digital cash (the former U.S. issuer of 
Digicash's ecash product) account and actually having it work the way it 
should, and just the overhead/costs of using PGP.

Now on this X-Y graph plot the "blobs" where benefit/cost clouds of oints 
are found. The 45-degree line is where the "costs" equal the "benefits." 
(These values change somewhat in time, of course, but the general point is 
still clear I expect.) Anything _below_ this 45-degree line is "cost 
effective": benefits > costs. Anything _above_ this line is NOT 
cost-effective: costs > benefits.

(In the economics of black markets, or illegal activities, we can expand 
these terms a bit. For example, "costs = costs of being caught x chance of 
being caught." An illegal action which will result in a $100K fine but 
which is only expected to be caught 1% of the time has a resultant cost of 
$1K. This is the "expected cost." Obviously, the idea of crypto and 
untracebility tools is to alter the equation by reducing the chance of 
being caught.)

RATIONAL ACTORS
The obvious point is that rational actors never pay more for untraceability 
than they get back in perceived benefits. Someone will
not pay $1000 for privacy/untraceability technology or tools that only nets 
them $500 in perceived benefits.

They won't spend $1.00 in tools to net them 10 cents in perceived benefits.

THE SWEET SPOT
The "sweet spot" for privacy/untraceability tools is out of the "millicent 
ghetto" so much of the focus has beenon, and is even out of the "private 
Web surfing to avoid company tracing" ghetto, roughly at the tens of 
dollars levels. (It is hard to imagine how the "cost" of having Pillsbury 
know your baked good preferences is more than some trivial amount. This is 
the "ghetto" of low value transactions. However, not having the FBI know 
your are interested in "Lolita" images can be orth many hundreds of 
thousands of dollars in terms of avoided jail time, fines, loss of 
employability, etc.

(Do I think many pedophiles will, accordingly, pay hundreds of thousands 
for technologies to make them untraceable? Of course not, for reason 
psychologists are familiar with. But they'll pay some amount, and that 
amount may dwarf the aggregate value of what all of the "millicent ghetto" 
dwellers will pay.

Things start to get "interesting" at the thousands of dollars for tools for 
tens or hundreds of thousands of dollars in benefits. (By the way, the same 
applies to crypto per se. The military has "crypto specialists" and "crypto 
shacks" on board ships. But these cost a lot of money in training, 
procedures, and equipment. Millions of dollars a year for a ship, for 
example. Do the math. Real crypto is more than just strength of algorithms 
and keys: it's this economic trade-off. Too much of "why don't people use 
crypto more?" whines fails to see this basic point.)

The "sweet spot" often, practically by definition, involves putatively 
illegal activities: child porn, plotting revolution in Saudi Arabia, 
selling corporate secrets, distributing banned materials, etc. Only in 
these situations are the "costs of failure to be untraceable" high enough 
to make spending money and time learning to be untraceable worthwhile. It 
is not surprising that "those with nothing to hide" tend to put their money 
into their local bank branches under their own names while "those with 
something to hide" tend to open Swiss bank accounts.Again, draw this region 
as a blob far to the right on the X-axis and, we hope, not very high up on 
the Y-axis. Meaning, advances in crypto, remailers, digital money, etc. 
will make this "sweet spot" truly sweet.

CORPORATIONS AND ACADEMICS FOCUS ON THE "GHETTO" NEAR THE ORIGIN
Still, corporations and academics focus on the "near the origin" blobs: 
millicent payment schemes, slight Web surfing untraceability tricks, subway 
tokens, etc. Because to focus on the real sweet spot is to admit to working 
on crypto anarchy, untraceable revolutionary cells, child porn rings, all 
that good happy stuff. The stuff people want to be untraceable for--and are 
willing to pay for.

This is the failure of nerve that all corporations and "reputable" 
academics face.

CONCLUSION:
To really do something about untraceability you need to be untraceable. 
Draw this graph I outlined. Think about where the markets are for tools for 
privacy and untraceability. Realize that many of the "far out' sweet spot 
applications are not necessarily immoral: think of freedom fighters in 
communist-controlled regimes, think of distribution of birth control
information in Islamic countries, think of Jews hiding their assets in 
Swiss bank accounts, think of revolutionaries overthrowing bad governments, 
think of people avoiding unfair or confiscatory taxes, think of people 
selling their expertise when some guild says they are forbidden to.

Most of all, think about why so many efforts to sort of deploy digital cash 
or untraceability tools have essentially failed due to a failure of nerve, 
a failure to go for the brass ring.
-----------------------------------------

steve

Date: Fri, 28 Dec 2001 12:46:41 +1100
From: "Michael H. Voase" <[email-masked]>
Subject: Re: An idea for sustainable file sharing.
Sender: [email-masked]
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Reply-to: [email-masked]
Organization: Castle Industries P/L

Eastlake III Donald-LDE008 wrote:
> 
> Hi Michael,
> 
> While I don't want to be too strict unless discussion gets out of hand, the politics of  national laws regulating intellectual property and discussion of business models, such as who pay who what %, are really beyond the scope of the IETF.
> 

	Understood. The inclusion of % figures is mostly for
illustration and to get the idea across. Considering your response,
I seem to have transferred most of the idea, but you have missed
something.

> A protocol to handle payments for multiparty file sharing might be within the scope of the IETF although its not one of the current goals of the TRADE WG.
> 

	Understood. However, considering that this concept is a form
of trade across the internet, I thought that the idea may be relevant
to your WG.

> I believe there already exist file sharing systems or proposals for file sharing systems which do provide for the flavor of payment you suggest.  Check out MojoNation http://www.mojonation.net/ 

	Ahh yes, I remember MojoNation now. Not the same MojoNation
that doesn't exist anymore?? There is one problem with
the MojoNation paradigm. Like any software company, they wanted their
monopoly on the system. That's the way software companies think.
Thus they were the software provider AND the paymaster. This fell to
one side because there was no openness and accountability. The software
was not open, the protocol they used to talk to their back ends was
not open. Thus software providers such as napster could not compete
on the level playing field. MojoNation wanted it all, and for everything
else to go away. That is why people did not trust it, and as such why
they
did not use it.

	That what makes this system different to MojoNation. It is
intended to be a _level_ playing field that ALL software providers
can compete fairly in, including Open Source projects. For example,
if the Apache group wrote a payment aware module, then they could
register their software with the payment service and start receiving
payments for people using their software. From there, they would
start pulling in their 2.5% cut on transactions.

	The idea behind MilleniPay is that it is inclusive, rather
than exclusive. My ultimate goal is to outline an Open  protocol
specification that software providers can then use to make their
applications payment aware. The protocol spec will apply to:

1) communications between the client software and the payment service.
2) communications between the server software and the payment service.

	The protocol used between the server and the client will
be dependent on the software in use with one small caveat. There
would need to be some addition information sent from the client
to the server, but this can be done in a protocol dependent
manner. For example, in the case of the HTTP protocol, a couple
of additional header fields would need to be sent, but its nothing
the protocol couldn't handle already.

	Anyways, that what makes MilleniPay novel. Its Openness.

Cheers Mik.

Date: Thu, 27 Dec 2001 13:46:27 -0800
From: IANA <[email-masked]>
Subject: RE: IOTP Brand registration of "atCredits"
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked], [email-masked]
Importance: Normal

Dear Donald,

Per your request, the following IOTP BrandID has
been registered with Ronald Duncan as the point
of contact:

"atCredits"  - @UK PLC         <[email-masked]>

Please contact the IANA if the contact information 
changes.

Best regards and have a Happy New Year!

Michelle S. Cotton
IANA Administrator

-----Original Message-----
From: Eastlake III Donald-LDE008 [mailto:[email-masked]]
Sent: Thursday, December 27, 2001 9:52 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: IOTP Brand registration of "atCredits"

Dear IANA,

If you haven't gotten a request and done so already, please add

	atCredits

as a registered IOTP BrandID to

	@UK PLC

with contact

	[email-masked]

Thanks,
Donald, Chair, TRADE-WG

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

Content-return: allowed
Date: Thu, 27 Dec 2001 13:19:15 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: An idea for sustainable file sharing.
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]

Hi Michael,

While I don't want to be too strict unless discussion gets out of hand, the politics of  national laws regulating intellectual property and discussion of business models, such as who pay who what %, are really beyond the scope of the IETF.

A protocol to handle payments for multiparty file sharing might be within the scope of the IETF although its not one of the current goals of the TRADE WG.

I believe there already exist file sharing systems or proposals for file sharing systems which do provide for the flavor of payment you suggest.  Check out MojoNation http://www.mojonation.net/ (http://www.wired.com/news/technology/0,1282,37892,00.html) or Potlatch http://www.potlatch.net/2001/03/02.html or Tipster http://tipster.weblogs.com/tipster/ or many others.  Your general idea does not seem that unique. Here is a Business Week article on the topic: <http://www.businessweek.com/ebiz/0008/ep0821.htm>.

Donald

-----Original Message-----
From: Michael H. Voase [mailto:[email-masked]]
Sent: Thursday, December 27, 2001 3:49 AM
To: [email-masked]
Subject: An idea for sustainable file sharing.

Greetings,

	I would like float a suggestion for creating a sustainable
model for file sharing that permits copyrighted information (music,
literature, artworks, etc) to be shared among users whilst supporting
payments to the copyright holders.

	As you probably are aware, organizations such the RIAA and
the MPAA are currently on the warpath to shut down file sharing
networks (such a napster, gnutella, etc), and replace them with a
new system that will probably only favor its own members. I find
this possibility quite alarming as it wont address the needs of the
community, or strike a fair balance with independent performers.

	My own main motivation for engaging this issue is sheer
terror. I am terrified that draconian, freedom destroying laws such
as the SSSCA will be imposed upon Americans, and through the WTO, on
the rest of the world*. I am also terrified of the companies involved,
who have openly threatened the community with its insistence on
imposing copyright protection technologies that remove a users
basic rights.

	Lastly, I would never forgive myself if I sat on my
hands and did not act on this idea.

	In a nutshell, what I would suggest is the creation of a
payment service that is independent of any software company, that
tracks sales of copyrighted works across file sharing networks.
This payment service would have to be a Public Utility, and would
need to be accountable to the global community. It would also need
to be completely open and transparent. No shady back room deals.
The payment service must also permit the free sharing of public
data. In this instance, the file sharing software would default
back to its normal (read: current) mode of operation.

	Now here's the catch. You could not simply 'impose' such a
solution on users and file sharing software providers. They would
simply reject it. So rather than imposing, why not offer an incentive
to support the payment service by reserving a portion of the sale
to the parties involved. In my view, the main parties involved are:

1) The copyright holder.
2) The software provider.
3) The user(s) who provide storage space for the content.
4) The payment service (it could not be done for free).

	To draw the analogy to a classical retail model, the user(s)
provide the 'shelf space' where the goods are advertised. The software
acts as the conduit to conduct the transfer, and lastly, of course, the
copyright holder provides the content.

Now consider a case for a (simplified) classical transaction.

In the classical model, the retailer buys the quantity of goods from
the copyright holder. The goods are transported to the premises by the
courier service and the cost of transport is added to the price.
Finally,
the retailer adds her own margin to the product, and places in on her
store shelves. Joe Public comes in and buys the goods at the advertised
price.

Now consider a case for a current Napster transaction:

First the user downloads the goods from another user. The user then
places the content in the outgoing directory. Another user comes
along and downloads the content from that directory.

Now what is missing in the napster transaction as compared to the
classical model is the exchange of money. There is a reason for this.
There is no incentive or framework to support payment and the supplier
(and the software provider) get nothing from the transaction. Thus
currently, the copyright holder gets nothing as well.

	Not only is this illegal, it is an unworkable situation.
If permitted to follow through to its ultimate destination, artists
will avoid the internet, or worse, go broke and receive no reward
for their efforts. A cultural wasteland would evolve where people
no longer want to be artists or musicians, because there will be no
future in it. A grim future indeed.

	Now compare this with a future situation where the
infrastructure has been supplied and incentive has been reserved
for the participants. The incentive is payment for participation.

First the user downloads the content using payment aware software.
The software contacts the payment service and announces the
transaction. The cost of the transaction is deducted from their
account (or barred in the case of insufficient funds). The transaction
is raised at the payment service, and relevant details are sent back
to the user. The user then downloads the content from the serving
machine(s) which is also using payment aware software. The user receives
the content and the transfer details are sent back to the payment
service and the transaction is completed. At the payment service,
the servers correlate who was involved in the transaction, divides
up the payment between:

	1) The Artist (85%)
	2) The software provider (5% - 2.5% each if different client/server
software is used)
	3) The user(s)** who supplied the content (5%).
	4) The payment service (5%).

	The percentage figures are not cost calculated as yet
since I haven't designed the boiler plate yet and estimated costs.
However, I think it would be important to make the cuts equal so
that arguments of who gets a bigger slice are eliminated. This way,
there is no argument about who gets the biggest slice, the Artists
must for a very important reason. Distributing content over the
internet as opposed to classical methods is far more cost effective.
Distributed file sharing services are extremely efficient at
disseminating data. Thus the costs of delivering goods is very cheap,
thus more transactions can be handled in a small amount of time.

	However, the biggest question is does this survive the
incentive litmus test?	

Q1.	Would the file sharing software writers be inclined to add
support for this?

A1.	I would like to think so. Considering they haven't received
a brass razzoo on their software, suddenly having a stable income
stream would be a boon to them. This also includes Open Source
projects who have been devoid of a reasonable business model since
the beginning. It would create a very different outlook on the entire
software field. However, I would like to add that Open Source projects
would probably still get ripped off with unscrupulous web masters and
admins rewriting their own accounts into the software at the expense
of the project. However, most Open Source supporters would probably
do the right thing and let them have their dough.

Q2.	Would the users want to use this?

A2.	Again I would like to think so. If you dangle the offer of
getting paid to run a piece of software on your computer to share
files around, I would be inclined to say yes. This would be the murky
part though, some would rather abuse than use. However, considering
the lively hood of the software supplier would be counting on their
co-operation, Joe Public might not get a choice in this regard.
Open source software users might be a different story, but I will
cover this another time.

	However, I do believe most normal people are honest, and
really would like to support their favorite artist. Mostly since
they know that if they don't, their artists will stop performing.
As for myself, I would be preferentially using this system to
supply my own music needs in future. I don't mind paying for music
when I know that the majority of the money goes straight to the
artist.

Q3.	Would the artists support this?

A3.	I would say so. Since this would be an open system, any
artists who has produced original work would be welcome, with no
need for them to hand over the copyright on their work. Likewise
authors, painters, graphic designers, etc. The payment service
could also act as a 'conduit' between users who wish to publish
an artists work, and the artists themselves. Once placed in contact
with each other, the payment service can step back and allow
each party to negotiate directly.

Q4.	Would the publishing houses support this?

A4.	It really doesn't matter what the publishers think. Its
the artists themselves who create the content, not the publishers.
I dare say that initially, they would reject this idea out of hand,
which is why I wouldn't be bothered telling them about it. However,
when they finally figure out this would probably be the only way to
be paid reliably for their content, they would probably come around
in the long run.

	Anyways, that's the skinny. All comments and criticisms welcome.
I am sending this info to your group since I consider you people to be
the best qualified to judge and comment on this concept. Considering
that you all value your freedom, as I value my freedom.

	I have lots more stuff on this, but that's enough for an
introduction...

	BTW, don't laugh, but I have tentitively called this the
'MilleniPay' system, for want of a better name.

	Of course, this document is copyright Michael H. Voase (c) 2001.
Released to you under the terms of the GNU public license version 2 or
optionally any later version.

	All rights are reserved to prevent more unscrupulous individuals
thieving it and turning it into a money printing machine.

Cheers Mik.

* In my own country, for example, the US has imposed sanctions on
the importation of lambs from Australia. For the Australian government
to ever get these sanctions lifted, we would need to join a 'free'
trading block. The conditions of which, as you guessed, are adopting
US style laws such as the DMCA and probably the UCITA as well.

** Some file sharing software uses 'multipoint' download to speed
the process up. It would need to be supported, and adds an extra
layer of complexity, but considering the speed of computers these
days, I still think its possible. My own suggestion for splitting
the payment is based on percentage of file supplied. If one user
supplies 25% of the content, they receive 25% of the 5% cut with
the rest going to the other users involved.

Content-return: allowed
Date: Thu, 27 Dec 2001 12:52:28 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: IOTP Brand registration of "atCredits"
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>

Dear IANA,

If you haven't gotten a request and done so already, please add

	atCredits

as a registered IOTP BrandID to

	@UK PLC

with contact

	[email-masked]

Thanks,
Donald, Chair, TRADE-WG

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

Date: Thu, 27 Dec 2001 19:48:39 +1100
From: "Michael H. Voase" <[email-masked]>
Subject: An idea for sustainable file sharing.
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Organization: Castle Industries P/L

Greetings,

	I would like float a suggestion for creating a sustainable
model for file sharing that permits copyrighted information (music,
literature, artworks, etc) to be shared among users whilst supporting
payments to the copyright holders.

	As you probably are aware, organizations such the RIAA and
the MPAA are currently on the warpath to shut down file sharing
networks (such a napster, gnutella, etc), and replace them with a
new system that will probably only favor its own members. I find
this possibility quite alarming as it wont address the needs of the
community, or strike a fair balance with independent performers.

	My own main motivation for engaging this issue is sheer
terror. I am terrified that draconian, freedom destroying laws such
as the SSSCA will be imposed upon Americans, and through the WTO, on
the rest of the world*. I am also terrified of the companies involved,
who have openly threatened the community with its insistence on
imposing copyright protection technologies that remove a users
basic rights.

	Lastly, I would never forgive myself if I sat on my
hands and did not act on this idea.

	In a nutshell, what I would suggest is the creation of a
payment service that is independent of any software company, that
tracks sales of copyrighted works across file sharing networks.
This payment service would have to be a Public Utility, and would
need to be accountable to the global community. It would also need
to be completely open and transparent. No shady back room deals.
The payment service must also permit the free sharing of public
data. In this instance, the file sharing software would default
back to its normal (read: current) mode of operation.

	Now here's the catch. You could not simply 'impose' such a
solution on users and file sharing software providers. They would
simply reject it. So rather than imposing, why not offer an incentive
to support the payment service by reserving a portion of the sale
to the parties involved. In my view, the main parties involved are:

1) The copyright holder.
2) The software provider.
3) The user(s) who provide storage space for the content.
4) The payment service (it could not be done for free).

	To draw the analogy to a classical retail model, the user(s)
provide the 'shelf space' where the goods are advertised. The software
acts as the conduit to conduct the transfer, and lastly, of course, the
copyright holder provides the content.

Now consider a case for a (simplified) classical transaction.

In the classical model, the retailer buys the quantity of goods from
the copyright holder. The goods are transported to the premises by the
courier service and the cost of transport is added to the price.
Finally,
the retailer adds her own margin to the product, and places in on her
store shelves. Joe Public comes in and buys the goods at the advertised
price.

Now consider a case for a current Napster transaction:

First the user downloads the goods from another user. The user then
places the content in the outgoing directory. Another user comes
along and downloads the content from that directory.

Now what is missing in the napster transaction as compared to the
classical model is the exchange of money. There is a reason for this.
There is no incentive or framework to support payment and the supplier
(and the software provider) get nothing from the transaction. Thus
currently, the copyright holder gets nothing as well.

	Not only is this illegal, it is an unworkable situation.
If permitted to follow through to its ultimate destination, artists
will avoid the internet, or worse, go broke and receive no reward
for their efforts. A cultural wasteland would evolve where people
no longer want to be artists or musicians, because there will be no
future in it. A grim future indeed.

	Now compare this with a future situation where the
infrastructure has been supplied and incentive has been reserved
for the participants. The incentive is payment for participation.

First the user downloads the content using payment aware software.
The software contacts the payment service and announces the
transaction. The cost of the transaction is deducted from their
account (or barred in the case of insufficient funds). The transaction
is raised at the payment service, and relevant details are sent back
to the user. The user then downloads the content from the serving
machine(s) which is also using payment aware software. The user receives
the content and the transfer details are sent back to the payment
service and the transaction is completed. At the payment service,
the servers correlate who was involved in the transaction, divides
up the payment between:

	1) The Artist (85%)
	2) The software provider (5% - 2.5% each if different client/server
software is used)
	3) The user(s)** who supplied the content (5%).
	4) The payment service (5%).

	The percentage figures are not cost calculated as yet
since I haven't designed the boiler plate yet and estimated costs.
However, I think it would be important to make the cuts equal so
that arguments of who gets a bigger slice are eliminated. This way,
there is no argument about who gets the biggest slice, the Artists
must for a very important reason. Distributing content over the
internet as opposed to classical methods is far more cost effective.
Distributed file sharing services are extremely efficient at
disseminating data. Thus the costs of delivering goods is very cheap,
thus more transactions can be handled in a small amount of time.

	However, the biggest question is does this survive the
incentive litmus test?	

Q1.	Would the file sharing software writers be inclined to add
support for this?

A1.	I would like to think so. Considering they haven't received
a brass razzoo on their software, suddenly having a stable income
stream would be a boon to them. This also includes Open Source
projects who have been devoid of a reasonable business model since
the beginning. It would create a very different outlook on the entire
software field. However, I would like to add that Open Source projects
would probably still get ripped off with unscrupulous web masters and
admins rewriting their own accounts into the software at the expense
of the project. However, most Open Source supporters would probably
do the right thing and let them have their dough.

Q2.	Would the users want to use this?

A2.	Again I would like to think so. If you dangle the offer of
getting paid to run a piece of software on your computer to share
files around, I would be inclined to say yes. This would be the murky
part though, some would rather abuse than use. However, considering
the lively hood of the software supplier would be counting on their
co-operation, Joe Public might not get a choice in this regard.
Open source software users might be a different story, but I will
cover this another time.

	However, I do believe most normal people are honest, and
really would like to support their favorite artist. Mostly since
they know that if they don't, their artists will stop performing.
As for myself, I would be preferentially using this system to
supply my own music needs in future. I don't mind paying for music
when I know that the majority of the money goes straight to the
artist.

Q3.	Would the artists support this?

A3.	I would say so. Since this would be an open system, any
artists who has produced original work would be welcome, with no
need for them to hand over the copyright on their work. Likewise
authors, painters, graphic designers, etc. The payment service
could also act as a 'conduit' between users who wish to publish
an artists work, and the artists themselves. Once placed in contact
with each other, the payment service can step back and allow
each party to negotiate directly.

Q4.	Would the publishing houses support this?

A4.	It really doesn't matter what the publishers think. Its
the artists themselves who create the content, not the publishers.
I dare say that initially, they would reject this idea out of hand,
which is why I wouldn't be bothered telling them about it. However,
when they finally figure out this would probably be the only way to
be paid reliably for their content, they would probably come around
in the long run.

	Anyways, that's the skinny. All comments and criticisms welcome.
I am sending this info to your group since I consider you people to be
the best qualified to judge and comment on this concept. Considering
that you all value your freedom, as I value my freedom.

	I have lots more stuff on this, but that's enough for an
introduction...

	BTW, don't laugh, but I have tentitively called this the
'MilleniPay' system, for want of a better name.

	Of course, this document is copyright Michael H. Voase (c) 2001.
Released to you under the terms of the GNU public license version 2 or
optionally any later version.

	All rights are reserved to prevent more unscrupulous individuals
thieving it and turning it into a money printing machine.

Cheers Mik.

* In my own country, for example, the US has imposed sanctions on
the importation of lambs from Australia. For the Australian government
to ever get these sanctions lifted, we would need to join a 'free'
trading block. The conditions of which, as you guessed, are adopting
US style laws such as the DMCA and probably the UCITA as well.

** Some file sharing software uses 'multipoint' download to speed
the process up. It would need to be supported, and adds an extra
layer of complexity, but considering the speed of computers these
days, I still think its possible. My own suggestion for splitting
the payment is based on percentage of file supplied. If one user
supplies 25% of the content, they receive 25% of the 5% cut with
the rest going to the other users involved.

Content-return: allowed
Date: Wed, 05 Dec 2001 11:42:00 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: FW: TRADE Agenda for Salt Lake City
To: "[email-masked]'" <[email-masked]>

As you can probably guess, I produced this by editing from the previous Agenda. Please ignore the first sentence in the message. This is for the Salt Lake City meeting http://www.ietf.org/meetings/IETF-52.html

Donald

-----Original Message-----
From: Eastlake III Donald-LDE008 [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2001 11:33 AM
To: [email-masked]
Subject: TRADE Agenda for Salt Lake City

Here is an initial agenda for the working group meeting at the 51st
IETF meeting in London next week.

TRADE WG Agenda (MONDAY, December 10, 2001)
Murano Room

13:00   Agenda Bashing

13:10   Documents Status

13:25   IOTP/ECML/Voucher Implementation Experience

13:35   XML Voucher: Generic Voucher Language & API
	draft-ietf-trade-voucher-lang-02.txt
	draft-ietf-trade-voucher-vtsapi-00.txt

13:50  ECML V2 Specification
	draft-ietf-trade-ecml2-spec-02.txt

14:00   SCCD using ECML

14:10   Charter Update

14:30   Schedule Future Actions/Meetings

14:40   End

Content-return: allowed
Date: Wed, 05 Dec 2001 11:33:11 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: TRADE Agenda for Salt Lake City
To: "[email-masked]'" <[email-masked]>

Here is an initial agenda for the working group meeting at the 51st
IETF meeting in London next week.

TRADE WG Agenda (MONDAY, December 10, 2001)
Murano Room

13:00   Agenda Bashing

13:10   Documents Status

13:25   IOTP/ECML/Voucher Implementation Experience

13:35   XML Voucher: Generic Voucher Language & API
	draft-ietf-trade-voucher-lang-02.txt
	draft-ietf-trade-voucher-vtsapi-00.txt

13:50  ECML V2 Specification
	draft-ietf-trade-ecml2-spec-02.txt

14:00   SCCD using ECML

14:10   Charter Update

14:30   Schedule Future Actions/Meetings

14:40   End