Topic: [DRAFT] - Building a new e-Currency (Read 1121 times)

I've actually been considering something like this (I referenced it in my previous account here but I've forgotten the username and password, so...).

The basic concept I had is that rather than being paid for finding rare hash strings, you are paid for the reliability you bring to the network as a whole.
- The block chain, if it still exists, no longer encodes transactions.
- Your 'money' is instead an 8-kilobyte random number with a value associated with it. When the network first assigns you the currency, you generate the random number and communicate individual private hashes with other participants in the network, along with one of your public keys. The hashing method and the public key method will be called by library - that is, updating to a new hash or a new signature format is inherent in the software, and moving on from SHA512/Whirlpool/RSA/Elliptic would be fully backwards compatible with other clients (and possibly even a bit forwards compatible). Possibly, there would be two hashes and two signatures sent. The idea is that it won't be enough to crack one method - you have to crack both, at the same time, and keep this fact hidden from the world long enough to exploit it. Cracking two methods alone only shuts the system down, however - you need to break all four in order to destroy the integrity of transactions.
- Transactions are engaged by the destination announcing that they hold a piece of a token (there would be twelve or sixty or so pieces in a token, say, each with a public key and hashes associated with them). This gets confirmed by those who have the verifying data, and as individual tokens are announced, the destination (or destinations, if anonymizing) announces the new values and public keys associated with them. Only when all pieces are announced is the new owner of the token actually verified.
-- If the entire token isn't being transmitted, the token gets split, as with bitcoin. Without anonymization, this will reveal the other endpoint of the transaction.
-- However, clients can instead agree to communicate over anonymizing servers. The anonymizing servers announce the new token verification values for their clients. This means that only the anonymizing servers, and the value being exchanged, is known.

This makes it somewhat of a tradeoff. Anonymizing servers can of course be subject to subpoena, or may be in a country that is effectively compromised (though encryption can help this). Alternately, if all of your chosen anonymizing servers are working in collusion, they can pass out false hash values. They won't be able to pass out false public keys without noticing, however, so this problem should not be too risky unless the client for some reason chooses to verify with all of them at the same time. The anonymizing server will of course be able to charge a fee for this service (should probably set a default value).

In addition, there is a transaction fee that is collected by those IPs that verify the integrity of the transaction. When it sees a transaction being announced, if it has the appropriate hashes and keys stored, it will
1) Announce the signed message it received, containing the hash and proving that it actually does have the authority to verify the transaction.
3) In the event of a transaction needing a reversal, new messages will need to be exchanged, requiring the existence of a reversal key. The transaction fee would still be charged, but the victim of attempted fraud would at least keep the vast majority of their money (and only the portion of the transaction that got reversed would charge the fee, so the full charge wouldn't apply).

The transaction fee would be parceled amongst all those who successfully verified the integrity of a successful or reversed transaction. In order to reinforce the idea of providing value to the network, each ASN would divide an equal share of the transaction fee. From there, each 'half' of an ASN (based on allocated IP space) would get half the share (but of only one half is active, it gets the full share). Each half of that IP space would get half the share, etc. on down the line until individual IPs or /64s are seen.

To prevent a network explosion, rather than announcing new tokens and the resulting security validations for each individual transaction, the bootstrapping nodes instead keep a running total of how much the 'system' owes an individual set of keys, and once it reaches a certain amount, the verifiers can choose to announce a new token.

Money enters the system initially through bootstrap nodes. These are hardcoded nodes with static IPs and domain names that will have some measure of public accountability. They get initial supplies of the currency as above - divided between ASN, then how much of that ASN's numbering they are 'responsible' for, and their uptime. They are required to use a high portion of this to engage in initial verifications - they begin transactions with only themselves, and the other nodes on the system will pick up the transaction fees as long as they have the disk space and network access. As these rack up, the nodes can then announce their own tokens, and can participate in commerce.

- The seed currency will only be valid for self-transactions until it has been whittled down to a certain value. Should be enough to reward the bootstrap systems, but also convince others to engage in conversing with them.

The bootstrap systems will be hardcoded urls, which will keep track of active nodes as well as all other bootstrap systems. Nodes will communicated with bootstrappers and each other as needed.

---

I think there are several advantages to this process.
1) It does not waste processing power. Nor does it give too much advantage to people who have resources to blow. It only takes up those resources actually needed to maintain the integrity of the currency.
2) Because of this, it allows us to explore several different currency models simultaneously:
2a) Deflationary currency, as with bitcoin: once the seeding is done, that's it. If you lose your money, too bad.
2b) Flat currency: Currency must be refreshed in a self-transaction every few years, or else, at the expiry, nodes can announce their keys to claim the full value of that currency. This has a slight demurrage effect, but if the transaction fee is small it would be negligible.
2c) Combining the above with an actual demurrage or inflationary system. Seeding never stops - it's either taken from demurrage, pulled out of thin air, or both.
3) The anonymization is better than going through Tor. Both in actual anonymity (e.g. some spook controlling your exit node) and security.
4) People are rewarded for actually helping the network's integrity. Some network provider does not have a node? You can make a killing by providing one there. Some network provider is already saturated with nodes? Don't count on much.

Having bootstrap systems as a known quantity provides some measure of protection from botnets, but also makes it more vulnerable to government interference. However, this isn't too terribly different than Bitcoin "Some country needs to remain free."

For starters this is a draft, no I'll not start any project, at least just yet, it's meant to discuss ideas.

Following bitcoin motto, but not forking bitcoin - means a totally different project - what can we think about remove bitcoins nags such as:

* Removing IRC from the scenario - it's both: outdated and a weakness
* Removing the block chain - it's a huge nag, it allows eavesdropping within transactions, unless people start to use BTC on its primary function; Commerce; and it generates transactions enough for people to "hide in the mob" I bet some folks keep their eyes on the block chain, some for so long that can already enumerate the nicks of the payer and payee just by looking at the hash.

?

For my very drafty idea we could come up with a system that would work with server/client system, being the coins generated based not on hardware effort (energy should be preserved) but on server dedication. This would mean only those running servers would be able to generate coins clients would do what clients normally do... spend and use them.
Generating these coins would go through a different process and at small amounts at the time.
Each generated coin would need them to be recognized by a significant amount of servers in order to be valid.
Each transaction should be present only until it's validated by a necessary amount of servers, being forget afterwards (this would mean sort of a dynamic block chain).
And now... I came across the first nag I don't know how to solve; being it opensource I wouldn't be surprised if some server owners in a system like this wouldn't start to log the transactions... making them able to track coins just like the block chain does...