I just read the Darkcoin white-paper - it is good to see a coin implementing distributed mixing at a protocol level (as far as I understand it, the mixing is done partly at a protocol (using scripts), partly at a client level). However, I may be missing something, but I don't see the trust model being proposed being as solid as suggested. Network discipline is achieved through the arbitration of miners - the last two miners to work on the block decide whether a master node or whatever has handled the transaction properly, and if they both decide he/she hasn't they can take a forfeit from him (which is effectively held in deposit). The paper suggests that collusion between miners would be discouraged because: "In that case the pools users would learn of this and stop using that pool." - but this just doesn't ring true. Relying on pool members (who are making a profit from their pool's dishonesty) to make an ethical decision to switch pools? The users actually submitting the transactions - unless Darkcoin's infrastructure is substantially different from Bitcoin's - will have no say over who does and doesn't get to mine the block with their transaction on it, and so can't choose not to use certain miners; the only mode of volition available to them is to not use the coin, and it's a mode they'll willingly subscribe to. As I say, I may be missing something, but it looks like miner collusion can not be prevented.

Also, especially in the early days when uptake is low, the system seems to be relying on users voluntarily running scripts to send dummy payments to their own addresses, in order to fill up the slots in joined transactions, increasing anonymity and getting those transactions turning around faster. This seems not only highly optimistic, but also otiosely resource intensive - as well as accelerating difficulty increase and potentially shortening the march to the altcoin gallows. Though this be a pedantic grievance, and I'm certain in practice there shouldn't be too many problems if such scripts are by default enabled at a client level.

Lastly, forgive my ignorance, but the white-paper mentioned nothing about how those issuing transactions keep the exact recipient of their transactions secret from the master node - though I'd be very surprised if there isn't a mechanism for that built in; the details are probably in the CoinJoin paper.

Just a quick idea, any thoughts? I think some sort of message layer built into the protocol would be great (though how exactly it should be implemented needs some consideration). With the ability to send messages between users, people could design their own custom protocol extensions and clients to handle them. Three examples:

******************

1) Multi-pass contracts
Consider some sort of contract that requires a raw transaction to be passed around multiple users for signing before being broadcast. Traditionally this passing round would either have to be done manually, through a central service like Blockchain.info, or else through a client application that relies on a messaging protocol like e-mail/SMS/bitmessage or communicates with a central server or connects to a second P2P network (distinct from Bitcoin) to transmit and receive the messages.

With messaging, users could send special messages to each other's addresses which certain clients could parse and respond by opening a dialogue asking the user to sign, delay signing or reject the transaction (or for instance in the case of a 2-of-3 signatures transaction if the user who is to receive the funds by the transaction receives a message their client could automatically sign it because there is no risk). This could automate complex contract operations.

Example message:

Code:

<message protocol="#PROTOCOL">
<to>#ADDRESS</to>
<request>#SIGN_&_TRANSMIT</request>
[#RAW_TRANSACTION]
</message>

2) Trustless mixing

Rather than relying on a centralised server for mixer, or even a centralised server for collating outputs and signatures for trustless mixing, or having to connect to a second P2P network, a client (or a client add-on) could be designed that handles messages of a certain format/content.

A user would trasmit a message to the whole network of a certain form, containing only the output(s) of their intended mixed transaction, then other users wishing to participate in the mixing would add their outputs to the message and retransmit it, then when it had enough outputs (or a certain time limit had elapsed or whatever) it would (somehow) request all the participants to add their inputs, then would go round again asking for signatures. The exact mechanics of this are vague, I haven't really thought about this one in detail, but this is not the idea I'm proposing, just an example.



3) News and market data
Exchangers could transmit signed and time-stamped market price information every so often, which clients could pick up and display to users. Nodes with two messages signed by the same exchanger with the same id but with different time-stamps would simply delete the older one in favour of the newer one, meaning such updates would not bloat the "message chain" or whatever.

Similarly, Bitcoin/cryptocurrency news websites could broadcast news updates which expire after a certain time limit. Forums could even broadcast new posts which users could configure their client to look out for (e.g. threads started by certain users, new replies to certain threads). There are so many possibilities, this would be a really great feature.

**********

The point is that rather than clients having to rely on external servers/p2p networks or else having to lobby the dev team for a major change to the protocol, a messaging layer would enable new functionalities to be developed independently. Rather than a centralised decision about what protocol extensions should go in, individual clients can offer different services (which obviously won't be compatible with all users necessarily to begin with), and the popular ones will be implemented by all/most clients/wallets. The really popular ones can become "canon" and considered part of the core Bitcoin protocol itself.

The use of Bitcoin purely for decentralised messaging is pointless and would be underused, as there are plenty of dedicated services out there already providing this. But a messaging layer within the Bitcoin protocol would be a major advancement.

I don't think messaging should be implemented directly into the block-chain; not only would this bloat it, but it is pointless: there is no need to have a full public ledger of all (probably encrypted) messages that have ever been sent. Only the ones that haven't been dealt with need to be available. There are of course other issues to consider with regards to messaging, such as how to prevent spam (tx fees seem like the most obvious answer, but will people be willing to pay even trivial fees just to sign a transaction?). Apologies I haven't presented a full working concept, but I definitely think it's something to be looked into.

Any coin linked to a physical asset will have the problem of requiring a gateway step, translating it from its fiat/physical form to digital, perhaps with a restrictive interface - though for certain assets (e.g. teddy bears) AML laws will not be as strict. Coins pegged to digital assets however, such as disk space, bandwidth, instructions (for an off-site processing service) would require no such gateway step. The tokens could be traded freely through payment systems like Open Transactions/Ripple/Coloured Coins/Mastercoin/a new blockchain and then redeemed directly for services. If these services were themselves decentralised, then you would have a completely decentralised, asset-pegged currency, and I see this being the way to go for certain services (web-hosting, storage, cloud computing) - and by offering these resources yourself, you could generate coins that could be exchanged for other goods and services, or other currencies.

[I assume this goes here rather than "Alternative Cryptocurrencies" as coloured coins was originally suggested as an extension to Bitcoin rather than a currency in its own right. Move it if I'm wrong though.]

Fiat-coloured coins (or equivalent) are not a way to trade fiat on the blockchain. They are tokens representing fiat, and just like any other digital token one requires a gateway step to convert from "fiat" (in a bank account) to fiat-coloured coins. Unless being specifically used for reasons of anonymity or distrust of central authorities, fiat-coloured coins will not be viable if people are expected to pay exchange costs to buy/redeem the coins (negating the advantage of micro transaction fees) every time they buy or sell something online. They will only be viable if there is an incentive to hold onto the coloured coins and re-use them on other services.  This will occur only if there are enough services accepting the coins to make holding onto them rather than paying a fee to translate them back into universally accepted fiat-proper a good idea.


Comparison of different payment gateways:
********************

Fiat-coloured coins:
-(Negligibly) low fees for buyers (fixed ~10p atm for btc)
-No fees for merchants
-Pseudonymous
-No chargebacks (certainty of fate)
-Decentralised (trustless)
-No account requied
-Exchange costs (likely) in and out of currency

PayPal:
-PayPal has no fees for buyers or one-off transactions
-PayPal has fees for merchants
-Chargebacks
-Buyer-protection & seller-protection (essentially "free" insurance)
-Money can be spent directly from your bank account or payment card
-Legal protection as this is legally a "purchase"
-Non-anonymous (proof of ID required)
-Gateway can refuse transactions for political/biased reasons (e.g. WikiLeaks)

Visa/MasterCard debit cards:
-No fees for buyers
-Fees for merchants/receivers
-Can involve third-party payment processors for merchants
-Money can be spent directly from your bank account
-Legal protection as this is legally a "purchase"
-Fraud protection etc. (free insurance)
-Non-anonymous (proof of ID required)
-Gateway can refuse transactions for political/biased reasons (e.g. WikiLeaks)

Western Union/Moneygram:
-Fees for buyers
-No fees for sellers
-No chargebacks
-Can be more anonymous than PayPal/Visa/MasterCard

Centralised digital currencies like Ukash, Pecunix, Liberty Reserve (deceased):
-Often exchange fees in and out of currency
-Sometimes transaction fees for sender
-Sometime transaction fees for receiver
-Centralised (can go down and take everyone's money with them)
-Can be more anonymous than PayPal/Visa/MasterCard

********************

Sellers should be keen to accept payments in fiat-coloured coins because they offer advantages over the other four: they don't cost the seller anything like PayPal or Visa/MasterCard, they don't allow for chargebacks, they are less hassle (to send and to receive) and can then be used again by the seller incredibly cheaply and easily, so I would expect a quick adoption by service providers as bitcoin fever spreads.

Buyers who want greater anonymity (and large, respected merchants WOULD require proof of ID/account verification anyway) or else distrust central authorities (even though it's likely such coloured coins would need to be issued and backed by one) would be willing to pay a premium to use such a gateway so wouldn't mind paying the exchange fees to get their hands on them in the first place.

But "normal" buyers by and large would have no reason for choosing coloured coins over PayPal or debit cards. Though the transaction fees themselves are negligible, unless buyers had some source of income directly in coloured coins then they would have to buy some in advance of/at the point of sale, meaning exchange costs. Also, they throw away options like chargebacks, fraud protection, buyer protection whilst receiving no discount (they could pay more for these options from third-parties, but what's the point when they could get them free?). And because of the uncertain legal status of cryptocurrencies, they might have a much harder time invoking their statutory consumer rights if the seller was unscrupulous. Coloured coins present a distinct advantage for buyers over WU/MG and centralised digital currencies, but don't present a major advantage over PayPal and debit cards.

So while there is plenty incentive for merchants to adopt the payment system, there will be no major demand from most buyers yet, for whom using fiat-coloured coins for "normal" transactions will be no more than a gimmick. The only way this would happen would be if a bank (or some other institution) that allows you to withdraw/spend money by Visa/MasterCard (essentially acting as a gateway for the Visa/MasterCard payment network) would also act as a gateway/issuer on a decentralised payment network (coloured coins/mastercoin/ripple/open transactions) for no or negligible fees, allowing you to spend your account balance directly onto the blockchain. Such an institution would be almost impossible to set up in any country due to AML and needing Visa/MasterCard onboard (although if bitcoin REALLY takes off over the next few decades there could possibly be a reconsideration).

Coloured-coins will certainly have plenty of niche use cases, but in order to really challenge the status quo they need negligible exchange costs (if the demand for fiat-proper was equal to the demand for fiat-coloured, then in a fee-less P2P exchange the exchange costs would be negligible), a way to instantly transfer bank account funds into coloured coins and vice versa, legal status (so buyers are protected) and perhaps insurance against fraud/mis-selling offered as part of a bank account.

[excess liquidity]

RE-POSTED FROM NEWBIE SECTION: (original post: https://bitcointalk.org/index.php?topic=320853.msg3435294#msg3435294).
[I originally posted this in the newbie section, but it didn't really generate any discussion. The idea is very rough, vague and generally will not work in its current form - nor have I developed it any further since my original post. I'm simply re-posting this very rough concept to try and generate some discussion about whether a decentralised cloud storage service (could possibly also offer file-sharing, web hosting, cloud processing) utilising a cryptocurrency would be in any way viable.]



I have been lurking around here for the past few days, so I thought I would sign up and make a post. I realise this post does not really belong in this forum, however I also realise that 1) it will be moved to an appropriate forum (where I cannot currently post) 2) it will raise my post count to 1, so four hours later I'll be able to go to the forum it's been moved to and post.

Though I have a bit of casual knowledge about cryptography (from reading about PGP, Bitcoin etc over the years), I'm certainly not an expert. Nor have I done any programming in years (and even then it was only amateur). This idea therefore is not fully formed (I literally only dreamt it up a few hours ago). I am only giving a very rough notion with many flaws, in order to generate some constructive discussion about whether something like this might be in any way viable, or if it is not doable at all.

The idea is not purely crypto-currency, though it does involve crypto-currency as a core element (and the non-crypto-currency bit involves P2P, decentralisation, crytography etc. anyway), so I thought I would post it here. The idea is a decentralised cloud storage network ("swarm storage" I'll call it) which relies on a new cryptocurrency whose value is pegged to a unit of storage in the swarm. I'll call that cryptocurrency "SwarmCoin" for now, for want of a better name (though the "Coin" moniker unhelpfully suggests it's another Bit-clone altcoin, which it isn't). SwarmCoin allows users to buy storage space on the network in a decentralised way.

A while ago I became aware of a distributed (but not decentralised) swarm storage solution called SymForm (http://www.symform.com). Users can either buy storage from the company, or can get some storage for free by allocating some of their own hard-drive space for use by the swarm. At the moment they offer 1GB of free swarm storage for every 2GB of hard-disk space sacrificed. They also require that anyone donating disk-space to the cloud be constantly connected to the cloud (the service is aimed more at businesses). I don't know on their system how many different nodes a file is distributed to, but I would imagine it would be at least two. This means that if you donated two gigs to the swarm, getting one free, and you used that whole gig, then your gig of data would be held by at least two nodes taking up at least two gigs of the swarm's capacity and thus cancelling out (or even negating) your two gigs contribution. If everyone used up their allowance to the max, there wouldn't be enough space to go around, and that's not even including the people who pay for storage without contributing any disk space! The reason that their business model works of course is that by and large users DON'T use up all their allowance - there is excess liquidity in terms of storage space so they are able to offer a multiplier of 0.5 for free to everyone donating space, as well as selling space on top of that.

In the system I am proposing, which should be fully decentralised, nodes will not have near 100% uptime, so files will need to be distributed across a much larger number of nodes, and the effective storage capacity of the network will not simply be the sum of all donated storage, therefore the amount of excess liquidity could be much lower - it would likely take some testing on a real or pseudo-real network to get a good idea of how much liquidity we could afford to lose. Every node that donated x amount of storage capacity would receive k*x free. Because the nodes in our network won't (likely) be "always on", we measure donated/used storage in gibibytehours rather than just gibibytes. And nodes would receive their free storage in the form of SwarmCoins (SWC). For ease of demonstration, I will assume that 1SWC = 1GiBh, though in practice it might be better pegged to a different number of GiBh (or MiBh, TiBh etc.) This free storage (in the form of SWC) is a node's reward for providing capacity to the network (just as tx fees and new coins are miners' reward in bitcoin for processing transactions). They can either use the SWC for storage themselves, or sell them for fiat, bitcoin or whatever at an exchange. [There is one obvious issue this could cause, see below #1].

I shall now explain how the system will work: each SWC is made up of a pair of keys, one "public" and one "private", with a certain hash of the public key being the "address". I shall loosely call both this hash and the associated key-pair the address. Each address in the swarm functions like an account: all the files uploaded by the same address are linkable to each other, but files uploaded by different addresses with the same owner are not (necessarily). When a user uploads a file to the cloud, he first chooses an address (that he owns) to upload it with. The file is encrypted using some keypair the user owns (could be the address but not necessarily). Then a (non-encrypted) header is generated which contains meta-data, including a file id (which identifies the file amongst all the files uploaded by this address) and a version number (which identifies the file amongst its revisions). The header also includes the address's public key (or perhaps just the short address if it's possible to verify a signature with just the hash). The encrypted file is appended to the non-encrypted header, and the whole thing is signed with the address's private key. Only the owner of the private key used to encrypt the file can access its contents, keeping files on the storm secure. If the user wants to replace the file with a newer modified one, he encrypts the new one, creates a header using the same address and file id but a greater version number than the old file, signs it with the same address and broadcasts it. When any node that is hosting the old file picks up a file with the same address and file id but a greater version number, it checks the signature of the new file against the public key from the header of the old file (which must be exactly the same as the public key in the header of the new file anyway) and if it's valid, then whoever broadcast the new file must control the address that uploaded the old file so the node can be sure this is a genuine revision by the owner and can replace the file it's storing. If the owner of a file wishes to delete it from the swarm, they could broadcast a header with no file appended, with the same address and file id and a greater version number than the file to be deleted. Nodes would not keep empty headers with no file content so would just delete the file. As files would associated with addresses which would also hold SWC, the values held by these addresses would deplete at a rate of 1SWC per hour for every gibibyte of storage used (assuming 1SWC = 1GiBh). These depleted coins could either be divied up proportionally amongst the nodes that actually contributed towards the hosting as an extra reward (on top of the reward they get simply for making that capacity available) or else could simply be destroyed (or could reward miners for processing transactions).

The mechanics of the P2P network, deciding which nodes should host which files and how those files are sent to those nodes is little beyond me at this present moment (as I say, the idea has just come to me). But that is not really the discussion I want to have right now. What I'd rather focus on is the viability of a crypto-currency system to allow decentralised purchasing of swarm storage as well as providing rewards to those lending storage capacity. How could and how should it be implemented? One thing is obvious: the value of the SWC needs to be such that users feel sufficiently rewarded for sacrificing their hard-disk space (this may also include large data-centres capable of starting their own centralised cloud if they wished), whilst also giving good, competitive value for money - if it's alot cheaper to buy storage from a cloud, then there will be no demand for the swarm (and thus no demand for swarmcoin, and thus no real reward for those sacrificing hard-disk space, and therefore the whole thing collapses). This problem is COMPLETELY different from the one that Bitcoin (and many altcoins) aim to solve; bitcoin creation is done in such a way that supply increases at a predictable rate for a limited period, then stops so that there is never any inflation. The challenge here is completely different, therefore the normal "coins created by mining" formula can't just apply. As I have said repeatedly, this is a brand new idea I haven't had time to properly consider in depth, so I haven't yet come up with any elegant solution to currency value problem, but I would be very interested to see some discussion.

So in order for this to be viable, we need some suggestions on how coins are created, how transactions are processed (should the tried and tested miners + tx fee model be rolled out here, or is there a way we could force everyone donating capacity (and thus receiving rewards) to also process some transactions?) Should there be a bunch of coins pre-created and held in reserve by a "federal bank" that will release and buy-back coins to keep the value stable to begin with (protecting against speculative investors, market shocks etc.) that could eventually commit suicide, after which point the coin would obey strictly mathematical laws? Perhaps the coin's value shouldn't be strictly pegged to a unit of storage, and node operators can set their own minimum prices for storage?

Also it would be great to hear if anyone has any ideas about how one could mathematically implement a mechanism that causes coins to decay as storage is used, or cause coins to be created/redistributed when storage is donated. This system would likely require a radically different infrastructure from Bitcoin/most altcoins.

#1 - returning to the paragraph above where I was talking about contributors being given their "free storage" reward in the form of SWC that they could sell: the problem this would cause is that it makes peoples unused storage capacity transferable; meaning that people can sell their unused storage capacity rather than just leaving it unused, reducing the extra liquidity of the system to zero (or less) unless there is some incentive to hold coins rather than redeeming them. However, the fact that storage is sold in gibibytehours (or similar) means that coins will not all be "redeemed" simultaneously - someone who buys enough to store 1GiB for 1 month will redeem his coins 1 per hour for a month, meaning he will be "holding onto" some of the coins for up to 1 month minus 1 hour. There could be a security vulnerability if an attacker uploaded files simultaneously with multiple addresses, "redeeming" too many SWC at once - though the network would need to have some sort of provisions in place for dealing with excessive demand.

#2 - there might also be a (theoretical) issue with the fact that SWC (albeit their exact method of creation is not yet defined), at least those "produced" as rewards, reflect past network capacity rather than current capacity, so if the network were to shrink there might be issues.

These last two points particularly have been fairly rushed; I'll try and think more about them and solutions and perhaps come up with small-network examples. Sorry for the very raw (and vague) nature of the idea, but I thought it might generate some interesting/useful discussion. IF (and that's a big if) there is anyway something even remotely like this could be viable, the next step might be to consider swarm-processing, decentralised file publishing/web hosting - but let's not run before we can walk (if in deed we can walk at all).

Sorry about the length of this (and the vagueness in parts), I am rather tired

[excess liquidity]

I have been lurking around here for the past few days, so I thought I would sign up and make a post. I realise this post does not really belong in this forum, however I also realise that 1) it will be moved to an appropriate forum (where I cannot currently post) 2) it will raise my post count to 1, so four hours later I'll be able to go to the forum it's been moved to and post.

Though I have a bit of casual knowledge about cryptography (from reading about PGP, Bitcoin etc over the years), I'm certainly not an expert. Nor have I done any programming in years (and even then it was only amateur). This idea therefore is not fully formed (I literally only dreamt it up a few hours ago). I am only giving a very rough notion with many flaws, in order to generate some constructive discussion about whether something like this might be in any way viable, or if it is not doable at all.

The idea is not purely crypto-currency, though it does involve crypto-currency as a core element (and the non-crypto-currency bit involves P2P, decentralisation, crytography etc. anyway), so I thought I would post it here. The idea is a decentralised cloud storage network ("swarm storage" I'll call it) which relies on a new cryptocurrency whose value is pegged to a unit of storage in the swarm. I'll call that cryptocurrency "SwarmCoin" for now, for want of a better name (though the "Coin" moniker unhelpfully suggests it's another Bit-clone altcoin, which it isn't). SwarmCoin allows users to buy storage space on the network in a decentralised way.

A while ago I became aware of a distributed (but not decentralised) swarm storage solution called SymForm (http://www.symform.com). Users can either buy storage from the company, or can get some storage for free by allocating some of their own hard-drive space for use by the swarm. At the moment they offer 1GB of free swarm storage for every 2GB of hard-disk space sacrificed. They also require that anyone donating disk-space to the cloud be constantly connected to the cloud (the service is aimed more at businesses). I don't know on their system how many different nodes a file is distributed to, but I would imagine it would be at least two. This means that if you donated two gigs to the swarm, getting one free, and you used that whole gig, then your gig of data would be held by at least two nodes taking up at least two gigs of the swarm's capacity and thus cancelling out (or even negating) your two gigs contribution. If everyone used up their allowance to the max, there wouldn't be enough space to go around, and that's not even including the people who pay for storage without contributing any disk space! The reason that their business model works of course is that by and large users DON'T use up all their allowance - there is excess liquidity in terms of storage space so they are able to offer a multiplier of 0.5 for free to everyone donating space, as well as selling space on top of that.

In the system I am proposing, which should be fully decentralised, nodes will not have near 100% uptime, so files will need to be distributed across a much larger number of nodes, and the effective storage capacity of the network will not simply be the sum of all donated storage, therefore the amount of excess liquidity could be much lower - it would likely take some testing on a real or pseudo-real network to get a good idea of how much liquidity we could afford to lose. Every node that donated x amount of storage capacity would receive k*x free. Because the nodes in our network won't (likely) be "always on", we measure donated/used storage in gibibytehours rather than just gibibytes. And nodes would receive their free storage in the form of SwarmCoins (SWC). For ease of demonstration, I will assume that 1SWC = 1GiBh, though in practice it might be better pegged to a different number of GiBh (or MiBh, TiBh etc.) This free storage (in the form of SWC) is a node's reward for providing capacity to the network (just as tx fees and new coins are miners' reward in bitcoin for processing transactions). They can either use the SWC for storage themselves, or sell them for fiat, bitcoin or whatever at an exchange. [There is one obvious issue this could cause, see below #1].

I shall now explain how the system will work: each SWC is made up of a pair of keys, one "public" and one "private", with a certain hash of the public key being the "address". I shall loosely call both this hash and the associated key-pair the address. Each address in the swarm functions like an account: all the files uploaded by the same address are linkable to each other, but files uploaded by different addresses with the same owner are not (necessarily). When a user uploads a file to the cloud, he first chooses an address (that he owns) to upload it with. The file is encrypted using some keypair the user owns (could be the address but not necessarily). Then a (non-encrypted) header is generated which contains meta-data, including a file id (which identifies the file amongst all the files uploaded by this address) and a version number (which identifies the file amongst its revisions). The header also includes the address's public key (or perhaps just the short address if it's possible to verify a signature with just the hash). The encrypted file is appended to the non-encrypted header, and the whole thing is signed with the address's private key. Only the owner of the private key used to encrypt the file can access its contents, keeping files on the storm secure. If the user wants to replace the file with a newer modified one, he encrypts the new one, creates a header using the same address and file id but a greater version number than the old file, signs it with the same address and broadcasts it. When any node that is hosting the old file picks up a file with the same address and file id but a greater version number, it checks the signature of the new file against the public key from the header of the old file (which must be exactly the same as the public key in the header of the new file anyway) and if it's valid, then whoever broadcast the new file must control the address that uploaded the old file so the node can be sure this is a genuine revision by the owner and can replace the file it's storing. If the owner of a file wishes to delete it from the swarm, they could broadcast a header with no file appended, with the same address and file id and a greater version number than the file to be deleted. Nodes would not keep empty headers with no file content so would just delete the file. As files would associated with addresses which would also hold SWC, the values held by these addresses would deplete at a rate of 1SWC per hour for every gibibyte of storage used (assuming 1SWC = 1GiBh). These depleted coins could either be divied up proportionally amongst the nodes that actually contributed towards the hosting as an extra reward (on top of the reward they get simply for making that capacity available) or else could simply be destroyed (or could reward miners for processing transactions).

The mechanics of the P2P network, deciding which nodes should host which files and how those files are sent to those nodes is little beyond me at this present moment (as I say, the idea has just come to me). But that is not really the discussion I want to have right now. What I'd rather focus on is the viability of a crypto-currency system to allow decentralised purchasing of swarm storage as well as providing rewards to those lending storage capacity. How could and how should it be implemented? One thing is obvious: the value of the SWC needs to be such that users feel sufficiently rewarded for sacrificing their hard-disk space (this may also include large data-centres capable of starting their own centralised cloud if they wished), whilst also giving good, competitive value for money - if it's alot cheaper to buy storage from a cloud, then there will be no demand for the swarm (and thus no demand for swarmcoin, and thus no real reward for those sacrificing hard-disk space, and therefore the whole thing collapses). This problem is COMPLETELY different from the one that Bitcoin (and many altcoins) aim to solve; bitcoin creation is done in such a way that supply increases at a predictable rate for a limited period, then stops so that there is never any inflation. The challenge here is completely different, therefore the normal "coins created by mining" formula can't just apply. As I have said repeatedly, this is a brand new idea I haven't had time to properly consider in depth, so I haven't yet come up with any elegant solution to currency value problem, but I would be very interested to see some discussion.

So in order for this to be viable, we need some suggestions on how coins are created, how transactions are processed (should the tried and tested miners + tx fee model be rolled out here, or is there a way we could force everyone donating capacity (and thus receiving rewards) to also process some transactions?) Should there be a bunch of coins pre-created and held in reserve by a "federal bank" that will release and buy-back coins to keep the value stable to begin with (protecting against speculative investors, market shocks etc.) that could eventually commit suicide, after which point the coin would obey strictly mathematical laws? Perhaps the coin's value shouldn't be strictly pegged to a unit of storage, and node operators can set their own minimum prices for storage?

Also it would be great to hear if anyone has any ideas about how one could mathematically implement a mechanism that causes coins to decay as storage is used, or cause coins to be created/redistributed when storage is donated. This system would likely require a radically different infrastructure from Bitcoin/most altcoins.

#1 - returning to the paragraph above where I was talking about contributors being given their "free storage" reward in the form of SWC that they could sell: the problem this would cause is that it makes peoples unused storage capacity transferable; meaning that people can sell their unused storage capacity rather than just leaving it unused, reducing the extra liquidity of the system to zero (or less) unless there is some incentive to hold coins rather than redeeming them. However, the fact that storage is sold in gibibytehours (or similar) means that coins will not all be "redeemed" simultaneously - someone who buys enough to store 1GiB for 1 month will redeem his coins 1 per hour for a month, meaning he will be "holding onto" some of the coins for up to 1 month minus 1 hour. There could be a security vulnerability if an attacker uploaded files simultaneously with multiple addresses, "redeeming" too many SWC at once - though the network would need to have some sort of provisions in place for dealing with excessive demand.

#2 - there might also be a (theoretical) issue with the fact that SWC (albeit their exact method of creation is not yet defined), at least those "produced" as rewards, reflect past network capacity rather than current capacity, so if the network were to shrink there might be issues.

These last two points particularly have been fairly rushed; I'll try and think more about them and solutions and perhaps come up with small-network examples. Sorry for the very raw (and vague) nature of the idea, but I thought it might generate some interesting/useful discussion. IF (and that's a big if) there is anyway something even remotely like this could be viable, the next step might be to consider swarm-processing, decentralised file publishing/web hosting - but let's not run before we can walk (if in deed we can walk at all).

Sorry about the length of this (and the vagueness in parts), I am rather tired