I have been thinking about how you could create a coin that is stable in terms of fiat currency for a while now and for different reasons I don't believe long term in any of those currently out there.

The whole idea fundamentally hinges on something I call "proof of trust", which is an alternative to "proof of work" and "proof of stake". In fact this idea gets rid of the need to compensate anyone with newly mined coins, thus getting rid of a cause for inflation on the system.

I have written this part for the layman as best I could:
The crypto currency I propose is similar to Bitcoin in the way it uses public key cryptography for address control and how it uses a chain of verifiable transactions to make sure what addresses, owns what tokens of value.

What is different is how the double spend problem is solved, i.e how the chronology of transactions is established. If an account with only 1 token to it sends two transactions of 1 token to different accounts, then it is essential for peers to be able to reliably create consensus of which transaction is valid and which one is not. And pragmatically, the first one received by the network should be the one that becomes accepted, because if the latter became the accepted one, peers would in effect be able to reverse previously verified transactions. The question is how to establish the order transactions were received by the network. In short, "proof of work" protocols (like Bitcoin) establishes time or chronology by relying on the time it takes for CPU consuming operations to be solved by the network. The "proof of stake" protocol relies on the idea that peers with most value on the network have less incentive to be dishonest and break the network. Both fundamentally rely on the trust of something on the network, be it the majority of CPU donated to the network being honest or the majority of sizable stakeholders being honest.

Instead of relying on either of those two methods, my scheme would use what I call “time helpers”. Any peer can start their own time helper and peers can decide for themselves what time helpers they wish to trust. What a time helper will do on request of peers is to evaluate the validity of a transaction and sign the transaction with its own private key in case it is valid. When evaluating the validity of the transaction the time helper will check that there is enough coins on the account and that the transaction is properly signed by the sender etc. Additionally in the transactions data, the sender will have included a number signifying what number in the sequence of transactions this is. Again the time helper will only verify transactions with correct sequence number.
When a transaction is signed by a time helper, it will immediately share the signed transaction on the network, to make sure it is known on the network that this transaction was made.  Any peer receiving a transaction will always get the transaction verified by at least two time helpers it trusts, before it will consider the transaction completed.

This would in practice likely work much like how root certificates work in browsers. When you download any modern browser it will come with a default set of trusted “root certificates” representing the entities that ultimately make HTTPS connections possible. Any user can change what entities to trust, but most users are unaware of this or don’t bother changing it. This would presumably change fast, in case users trust was being maliciously exploited by any of these entities. This safeguard mechanism is probably enough in and of itself to discourage the majority of abuse.

There are still cases where double spend transactions are possible though:
A double spend occurs on the system when the transaction value originating from an address exceeds the value received by that address, leaving a negative balance, or when a sequence number is out of order.

Double spend transactions can become verified by time helpers in one of two ways:
1   A malicious peer sends his transaction to two or more honest time helpers simultaneously and they verify the transaction, before discovering the transaction that was sent to the other time helper.
2   A malicious time helper knowingly verifies a fraudulent transaction.
In case sequence numbers are in a correct order but a transaction verified by a time helper leaves the account with a negative balance, all transactions from the first one causing the balance to become negative and forward, are considered invalid. In this case it would be very obvious that the account holder was colluding with the time helper, but peers would not acknowledge the transaction causing the negative balance.
If on the other hand the attackers create a duplicate sequence number, things are not as simple. In case 2 above, an attacker can chose any sequence number he likes, but in case 1 he cannot.

The way other peers would interpret account balances (their own or otherwise) resulting from a set of double sequence transactions depends on how many of the transactions are verified by trusted time helpers:
•   If two or more of the sequence conflict transactions are verified by trusted time helpers, those transactions are all voided and the remaining amount on the account is seen as 0.
•   If only one of the sequence conflict transactions are verified by a trusted time helper, only that transaction is seen as valid. The other double sequence transactions are voided and the value of the voided transactions is destroyed.
•   If there are no trusted time helpers, all transactions are voided and the transaction amount is destroyed.
These rules also apply for all transactions with higher sequence numbers than the conflicting ones.

Lets examine what happens in different double spend scenarios:
If a malicious peer sends tokens to two verified time helpers at the same time and he thereby manages to create a set of transactions with duplicate sequence numbers, his tokens would be lost. The receiver, for example a merchant, expecting one of the transactions would only have to wait a little longer to make sure no double spends has occurred with the transaction. If no double spend has occurred after a few seconds the first transaction will have propagated the network (automatically handled by the software) and the attack is no longer possible. From the attacker’s point of view, this attack besides from not working, is not very interesting, as he loses his tokens no matter what.

In the case that an honest user somehow manages to send two transactions to two different time helpers in less time than it takes them to communicate, his tokens will not be lost. The software will not allow spending more than is in the users account, so the spend will result in a positive balance and additionally, the transaction data will include different sequence numbers.

If a malicious user utilizes his untrusted time helper to craft and verify a transaction with a fake sequence number, the receiver of the other transaction in the double spend has presumably already made sure that transaction was verified by trusted time helpers, so this new untrusted double spend transaction will have no effect. (See sequence conflict with only 1 trusted transaction above).

If a malicious user somehow manages to get his time helper trusted or hacks a trusted time helper etc. he can actually carry out an attack. That is he can transfer money to another user and then destroy those tokens, even after the receiver had verified that he had received the tokens. He can do this by maliciously signing a new duplicate sequence transaction, which will result in both transactions being voided and the tokens lost. The attacker would need to spend tokens under his own control for this to work though. And again, this is a rather pointless attack, it will cost the attacker money to spend the tokens that he later wants destroy. Further the unlucky receiver that has had his received tokens voided will now have evidence that a certain time helper is malicious. He can show this to other peers and people will very quickly come start distrusting this time helper. And as the users program will always make sure every transaction is double verified on receiving transactions, the “destruction” of the tokens is reversed, when people stop trusting the certificate of the malicious time helper.

I am very interested in constructive criticism, please try and find a flaw in the scheme and let me know if you can. But I am not very interested in the whole "good luck with your shit scam coin" type of feedback. If your negative feedback doesn't include logical arguments, then please refrain from posting it. Thanks.

So according to the link below, Bitcoin addresses are ECDSA public keys that have gone through a bunch of hash functions.
I understand why you would RIPEMD hash it, to make it shorter and I also understand why you would base 58 encode it to make it even shorter.
Lastly, I also understand why they hash it one more time to create a checksum that ensures people don't accidentally send to bogus addresses.

But what are the other steps for? Why for example SHA-256 hash before you RIPEMD hash?

List of steps are found here.
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

We are a small team currently working hard on establishing a new crypto currency exchange with a lot of innovative features coming and we are willing to allow one or more serious botters early access to our network.

What you, the botter would get:
- Free, 0% fee, crypto currency trading lifetime account
- Early access to the system and thereby first mover advantage for realizing cross exchange arbitrage when the site goes live
- Direct contact to a developer for support during development
- And even possibly a chance to influence the API through feedback

What we need is initial market depth once the exchange goes live and are therefore willing to offer the above items. A chance to be a first move botter on a market like this doesn't show up every day and the offer should be valuable to you even as the market saturates with other traders, as you get to keep being able to take cross exchange arbitrage before all those who don't have the 0% fee account.
And before you ask why we don't set up a bot ourselves, we would rather keep that as plan B since we have a lot of things that need to get done at the moment and therefore would rather outsource tasks like these that we don't plan to do long term anyway and also because it goes against the ToS on most other exchanges.

The level of exclusivity depends on the initial depth you can supply and how tight you are willing to keep your initial spread between buy and sell offers.

At the beta launch the site will support the following currencies: BTC, LTC, DOGE, NMC and EUR.

Please PM me for details, invitation requests or offers.

gmaxwell
Very good questions that I hadn't thought about.
What if it we aimed for 0,5% inflation but spread the spoils based on how many transactions were included in that block? Of course this would give the miners a real incentive to spam the network with transactions. But what if we required some local proof of work for each transaction, that the clients were expected to do themselves. Like hashing the transaction data with different salts until a salt with x number of zeroes in the end was found? Then this salt could be added to the transaction data for others to confirm easily. Each transaction data together with its salt had to be unique, so you couldn't spam the network with the same transaction. This local proof of work would also have to be less profitable for miners than just mining transaction proof of work made by others. That shouldn't require much, since you would be unlikely as a miner to receive the bonus for your bogus transaction anyway (win the block). Spamming would be very computationally intensive and spammers would in effect pay by loosing potential income from not using that computational power to mine.

As for if this is for bitcoin, I don't know if it can be implemented at this point with backwards compatibility. It would probably take a lot of work. Seeing as you are a moderator feel free to move the post if you feel it belongs in the other section. But please also feel free to continue to provide valuable feedback

Thanks for the answers

BurtW:
If by "public ledger system" you mean a block chain that everyone agrees on, then yes. A block chain like with bitcoin, just a different standard for what is stored in those blocks.

gmaxwell
I have not been actively following this board for a while. what is anti-dos? (anti denial of service I guess)?
I don't see the need for fees, if the mining bonus stays for ever (say at 0.5% inflation long term).
I agree that it couldn't scale if transactions had to stay secret for ever, but you could make public transactions that are older than say 30 days, to avoid this problem. I understand that later transactions in the Chain can reveal previous ones, but I don't see this as "brittle security," since it is still an improvement from BitCoin where everything is always visible. Also its not a problem as long as you don't spend your coin or send the rest of your coin to a new place every time you spend. But I will have a look at your links and reply thoroughly later!

Crossposted from something I added to the Anoncoin thread. I hope other people will look at this and reveal any flaw in the scheme they might find.

Ok, much of this will use PGP in reverse of the way it is normally used, so the key Public key will be kept secret and the key Private key will be given out. Therefore I will call the Public key the "Encryption key," and the Private key the "Decryption key" in the rest of this post.

Imagine two types of transactions in the block chain, one visible and one secret:
The visible one would include:
- the sender in plain text
- the receiver in plain text
- the amount in plain text

The secret one would include:
- sender in plain text
- The receiver id hashed with a salt, then encrypted with senders encryption PGP key (unique PGP pair for every transaction)
- The amount encrypted with senders encryption PGP key
- Parent transfer ID in plain text (transfer where the sender received the money he now wishes to spend)

Example
Let’s say we want to transfer coins we received in Transaction 1 (visible), to Bob in Transaction 2 (secret). Bob would take his id together with a salt and hash it and give us this hash. Now we take the hash and use our PGP encryption key to encrypt it together with the amount. We also give Bob our decryption key so he can privately verify the transaction when it goes out on the block chain, but we don’t give it to anyone else. Giving it out, would be the same as making the transaction visible. Of course any of the two parties now can make the transaction visible should they want to, by giving out the decryption key, but this is not a problem that can be fixed, as they are both aware of the transfer and could just tell people about it in any case.

Anyway Bob uses our decryption key to see on the block chain that it is his hash that is encrypted in the transfer, he sees the amount is right and he looks up the ID of the parent transfer and sees that we indeed have enough money from Transaction 1, that means it he can verify it. Also no one, not even we know Bobs real sender ID (only his salted hash) and only we and Bob know how much we actually send him.

But now Charlie doesn't know that we actually don’t have any money left, let’s try and buy something from him with money we already spent (Transaction 3). How can he know if we have the money? Well he gets our decryption key, otherwise he will think it is very weird and assume our payment is bogus. Then he looks at this new Transaction 3, he sees the reference to Transaction 1 where we got the money from, so that checks out. But he then searches for other transactions with references to Transaction 1 and he finds Transaction 2 that we made with Bob. But since he already has our decryption key, he also can read the amount we sent to Bob, and subtract it from the money we had and sees that we actually don’t have enough coin for the transaction to be valid. The rule is that older transfers take priority over new ones, so even if we “overspend” in Transaction 3, everyone agrees that Transaction 2 is still valid. Only Transaction 3 is to be ignored. Now Charlie knows Transaction 3 is invalid and doesn't hand over the goods we tried to purchase!

Later transactions can always verify by the receiver in this way, so if Charlie always verify it properly he can be 100% of the coin he receives. Charlie can also see Bob’s receiver hash of course, but that doesn't reveal Bobs sender ID and he can’t “dictionary attack” with the senders on the block chain, since Charlie doesn't know the salt.

But say Bob now wants to send some of the money we gave him to David (Transaction 4), how can David verify that Bob has the money when Transaction 4 refers to Transaction 2 which was secret? Well since it was secret, Bob has to make it visible to David, by sending our decryption key and the salt he used in that transaction to him. David can now verify Transaction 2 and that we were in fact the receivers and he can then verify Transaction 4 too and is happy that he received the coin.

Space issue:
Of course if David wants to spend the money from Transaction 4 he now must send both our and Bob’s decryption key and salt, together with his own and so on. In order for space for saved decryption keys and salts not to grow out of control long term, you could include a fix where senders would be forced to make old secret transactions visible by giving out the decryption keys and salts from those transactions. The network would not accept transfers from further down the "chain" unless outdated transactions in that chain become revealed by the sender at the same time.

Information of this revealed old Transactions are added to the block chain and supersede the older ones (that can be removed using a method that doesn't compromising the security of the block chain. I won’t go into this now). Now every one in the Chain can get rid of the decryption keys and salts from those outdated transactions.

Receiver address:
Your receiver address is a hash of your sender salted address, you can generate as many receiving addresses as you want for each sender address, just by changing the salt. This also means you can keep your sender address hidden to the person sending to you and you can have him send to you multiple times, without him even knowing he is sending to the same sending address.

What do you guys think about this? It is not easy to explain, do you understand it? If someone who understands this can verify that it seems to work, I will probably make some graphs to explain better. Have you found any flaws/mistakes?

I have an idea that would make transaction amounts anonymous and the receiver address completely hidden.

[Edit, clearified PGP use]

First of all much of this will use PGP in reverse so the key Public key will be kept secret and the key Private key will be given out.
Therefore I will call the Public key the "Encryption key," and the Private key the "Decryption key" in the rest of this post.

Imagine two types of transactions in the block chain, one visible and one secret:
The visible one would include:
- the sender in plain text
- the receiver in plain text
- the amount in plain text

The secret one would include:
- sender in plain text
- The receiver id hashed with a salt, then encrypted with senders encryption PGP key (unique PGP pair for every transaction)
- The amount encrypted with senders encryption PGP key
- Parent transfer ID in plain text (transfer where the sender received the money he now wishes to spend)

Example
Let’s say we want to transfer coins we received in Transaction 1 (visible), to Bob in Transaction 2 (secret). Bob would take his id together with a salt and hash it and give us the hash. Now we take the hash and use our PGP encryption key to encrypt it together with the amount. We also give Bob our decryption key so he can privately verify the transaction when it goes out on the block chain, but we don’t give it to anyone else. Giving it out, would be the same as making the transaction visible. Of course any of the two parties now can make the transaction visible should they want to, by giving out the decryption key, but this is not a problem that can be fixed, as they are both aware of the transfer and could just tell people about it in any case.
Anyway Bob uses our decryption key to see on the block chain that it is his hash that is encrypted in the transfer, he sees the amount is right and he looks up the ID of the parent transfer and sees that we indeed have enough money from Transaction 1, that means it is verified. Also no one, not even we know Bobs real sender ID and only we and Bob know how much we actually send him.
But now Charlie doesn't know that we actually don’t have any money left, let’s try and buy something from him with money we already spent (Transaction 3). How can he know if we have the money? Well he gets our decryption key, otherwise he will think it is very weird and assume our payment is bogus. Then he looks at this new Transaction 3, he sees the reference to Transaction 1 where we got the money from, so that checks out. But he then searches for other transactions with references to Transaction 1 and he finds Transaction 2 that we made with Bob. But since he has our decryption key, he also can read the amount we sent to Bob, and subtract it from the money we had and sees that we actually don’t have enough coin for the transaction to be valid. The rule is that older transfers take priority over new ones, so even if we “overspend” in Transaction 3, everyone agrees that Transaction 2 is still valid. Only Transaction 3 is to be ignored. Now Charlie knows Transaction 3 is invalid and doesn't hand over the goods we tried to purchase!
Later transactions can always verify by the receiver in this way, so if Charlie always verify it properly he can be 100% of the coin he receives. Charlie can also see Bob’s receiver hash of course, but that doesn't reveal Bobs sender ID and he can’t “dictionary attack” with the senders on the block chain, since Charlie doesn't know the salt.
But say Bob now wants to send some of the money we gave him to David, how can David verify that Bob has the money when our Transaction 2 was secret? Well since it was secret, Bob has to make it to David, by sending our decryption key and the salt he used in that transaction to him. David now verifies Transaction 2 and that we were in fact the receivers and he can then verify Transaction 4 too and is happy that he received the coin.

Space issue:
Of course if David wants to spend the money from Transaction 4 he now must send both our and Bob’s decryption key and salt, together with his own and so on. In order for space for saved decryption keys and salts not to grow out of control long term, you could include a fix where senders would be forced to make old secret transactions visible by giving out the decryption keys and salts from those transactions. The network would not accept transfers unless outdated transactions become revealed at the same time. Information of this revealed old Transactions are added to the block chain and supersede the older ones (that can be removed using a method that doesn't compromising the security of the block chain. I won’t go into this now). And since our coin now only have 10 secret transactions back to the nearest visible one, we only have to store those 10 decryption keys and salts.

Receiver address:
Your receiver address is a hash of your sender salted address, you can generate as many receiving addresses as you want for each sender address, just by changing the salt. This also means you can keep your sender address hidden to the person sending to you and you can have him send to you multiple times, without him even knowing he is sending to the same sending address.

What do you guys think about this? It is not easy to explain, do you understand it? Have you found any flaws/mistakes?

Yes we are printing too fast!
I think one solution to tie the printing rate to price change (without a central server) would be to look at circulation, which is already available in the blockchain.

I proposed this here a few weeks ago:
https://bitcointalk.org/index.php?topic=26380.0

I agree, the supply side is running wild.
This is why I suggested making it a factor of transactions (read https://bitcointalk.org/index.php?topic=26380.0)

Lets do an experiment, you give me all your bitcoins and I will give them to someone else, if he says he will also give them away and so on. Then lets look at block explorer and see how far it all went.
My best guess is that we will set off a chain reaction where every one just gives everything to everyone else who needs it.

cunicula I think you are the first person I am very close to agreeing with here!
Right now a transaction fee is paid voluntarily to speed up things, my proposal was to tax that fee.
So it WOULD be able to destroy (some) coins!
But thinking about it, more and more I think your idea is good, but instead of a tax, call it a minimum transaction fee, that a lot sounds better to most people

As for the "deflation margin", did I explain it properly? What do you think about it?

Trade able claims is an awesome idea! But you wont know the value of the kind of claims I am proposing before the maturity date is up. And yea you are right about the libertarians

There is a voluntary transaction fee being used at the moment. The higher the fee you pay, the faster miners will serve your transfer.


Velocity should not be hard at all to calculate, its all in the block chain. If you are talking about bogus transfers, then your point is correct, but I really don't think those are that big of a problem (and the voluntary transaction fee was introduced exactly to fight this in the first place).

Well, it sounds really bad to "tax" and if this was ever to be adopted, it would need to be accepted by a majority of anarchists and liberal types on this board and they don't generally know that mining is the same as inflating, which is the same as tax. Also people would have a slightly lower incentive to transact, so it wouldn't have exactly the same effect, but yea, almost.

Did you see my comment on spreading out the mining profit over time? The idea is, profit now at current rate and a promise of profit at later dates at future rates. Regardless of whether the rate is 0 now, the promise of return on a later date will still be worth something. If you did see this proposal but don't like it, please elaborate.

I expect to see a lot huge increase in the velocity over the next couple of years so I don't think controlling inflation will be a big problem long term. Also it is generally excepted that the coin is deflationary by nature. Short term inflation (sudden price drops) will quickly be eliminated by speculators (especially since they have the source code and can very accurately calculate the probable mining rate at the next period, in real time).

Another tool to further be able to fight inflation would be to calculate a "deflation margin" based on the volatility of the velocity. This just means if the money velocity was volatile last period (prices were volatile), we would allow for more deflation in this period. This would be to ensure that we don't pump out a lot of money this period to hit our deflation target, just to find out that next period the coin is very inflationary and we wish we could take all those coins back we just pumped out.

Ultimately, whether or not your idea is good comes down to whether or not taxing the already existing transaction fees and the "deflation margin" will be enough to cope with inflation or not. And to be honest I am not sure that it is.

0 interest, 0 growth?
Sounds like Japan done did it even before you thought it up
Maybe you should check out their historic GINI's.

Thank you cunicula, I too very much dislike those counterproductive comments.

But I am not suggesting that anyone would be mining at a direct loss ever (no one would ever have their bitcoins destroyed for mining.) Of course the loss will be real in that electricity costs money and miners might just turn off their rigs to save energy if transaction fees are not high enough. That is indeed a problem, but that same problem will also arise with the current bitcoin when no more coins can be mined. Actually that sounds like a real danger for today's bitcoin, since a lot of rigs will be turned off, leaving the network so much more vulnerable to the "51% attack".
As for a solution (under my system) maybe miners could be promised some of their returns to be delivered in the future, at what ever the rate is at that time? Like, you will get 25% of what the rate is today right now, then you will get 25% of what the rate is next month, at next months rate, then you will get 25% in two months at that times rate and finally the last 25% in three months at whatever the rate is at that time. It will take some time to get all the coins (length of time can of course be adjusted and should be decided by the miners themselves).

I think you raised a valid concern there, if you see other problems or things you dislike, please post them


Are you saying you would help me build it? I would be willing to write a very thorough specification if yes


Another good point. I don't really like the idea of a forced tax though, it is hard to say if it would have enough impact, but the transaction fees could be taxed. And as inflation causes more and larger transactions, the amount of total transaction fees would therefore also increase. Still as transaction fees are voluntary that means people can always transact for free if they want to. What do you think?

Its a beautiful thought, but honestly there is no way that would ever work.

Would love to, but unfortunately im not a coder, just an economist.

Before central banks most currencies in Europe were bound to gold or silver. The currencies were mainly used for trade (as opposed to speculation), like you foresee the bitcoin in the future. But the currencies were certainly not stable. I recently read about the influx of gold when the america was discovered and how the price of gold fell to 1/3 of its prior value. Extreme case, but I think you get the point. Bitcoin will get more stable, but will never really be stable.


Really good point, it will help to stabilize, but surely it wont be enough. Do you really think so and why?


There are ways which you could make this more or less manipulation immune.


The dollar is stable because it is more or less based on the system I am proposing.

.

While not precise, the velocity would be calculated far more precise than that which is used to control the inflation of say, the dollar. They calculate it using a consumer price index, which is itself just a survey of goods and services and how they change. Not very precise, but it works pretty ok.

Which concept exactly? Instability?


First of, it will NOT be an inflationary coin, as I wrote, I am suggesting stable deflation. That said, I understand your point that it is changing the rules and some people are not comfortable with that. As for the fake transactions, the time can be adjusted. Still with three hours, you would need to have a very substantial amount of the total amount of bitcoins to be able to make any real impact. Also that impact would be negated the second you stop transacting every 3 hours. Not a real problem.
NGDP targeting? This is a currency, "Bitcoin land" is not really real, thus it has no National Gross Domestic Product. I am actually proposing inflation/deflation targeting.

All I am saying is we could have more stability, how much exactly would only be a guess.
Volatility/stability DOES reflect shifting sentiment. What I am saying is simply that we can control the supply side.


You might actually be right about that. Scratch that then, it is not really important anyway (since that emergency scenario will probably never happen).

Also here's the full quote:

Also it seems that no one really likes this type of idea, so never mind (although I think the most important part of my arguments are still solid).

As I said bitcoin days destroyed would have to be a part of the function. So that transactions of money that just been transacted recently would weigh a lot less. Only when the last transaction of the money was older than some barrier would the transaction weigh in 100% on the total velocity. The time barrier could be set to something like 3 hours, but it would be better to set it dynamically based on the last total velocity. I know the number would not be completely precise, but I think it would still be more so than the velocity when calculated in the real world.

Also a single dude cheating would mean less and less, as more and more people get a hold of money.

Money supply is not only influenced by the nominal supply, the real supply has a lot to do with the velocity of money. Do you not believe in the Quantity theory of money?


I agree that those were some of the causes, but none the less there was a high degree of deflation http://en.wikipedia.org/wiki/Causes_of_the_Great_Depression


I know this is a problem. That is why I said bitcoin days destroyed should factor in (quickly transferring the same money will not destroy much bitcoin days). I think this problem can be fixed.


I agree with you to some extend, but when I used the word "regulting", I simply meant to say "lets change the rules a bit". There will be NO regulator. NO central authority. Only different set of rules. The hashing power of the combined network will still be the only "authority", the only difference is that the rule set will be different.

Thanks for your comments though, I hope we can get a discussion going about this.