Pages:
Author

Topic: [ANNOUNCE] The Proposal for EnCoin (Read 9455 times)

hero member
Activity: 798
Merit: 1000
October 20, 2011, 03:31:12 PM
It's a ton of work as I am completely revising it again, and I got stuck at one point which now I think I have a solution. Still so much stuff to put down as I'm trying to go a lot more into technical details. But I'm keeping the tech details separate so they don't cloud up the basic stuff. Haven't had the time to put into it yet, it'll be out when it's out. Wink
hero member
Activity: 798
Merit: 1000
October 11, 2011, 07:15:41 PM
a taste of the next proposal:

TD-1) Determining Speed of Currency Creation; Adjusting for Processing Power
Coin-Hours are used to determine how quickly currency has been created.

Coin-Hours = Number of Peers Per Mint Block * Time Between Mint Blocks

If there are 35 users paid in a given Mint Block and 3 hours have passed since the last Mint Block from that CoreNet, the Coin-Hours for this block is 35 * 3 or 105 Coin-Hours.

Coin-Hours are added to a value stored in the Consensus Block. The number of Coin-Hours and the number of coins created is kept track for a period of 30 coin-creation CBs. These 30 CBs are called a Coin Creation Period (CCP). 10 of these such periods are maintained in each CB with the newest overwriting the oldest. For a CB to count as a coin-creation CB, the following formula is used:

Minimum Coins to Count for CCP = # of Coins Minted in Last 10 CCPs / 300 * 0.50
OR
Minimum Coins to Count for CCP = 1,000

Whichever is higher. By multiplying by half in the first formula, the amount of coins required to increase the difficulty can go down over time so that it is not trivially easy to avoid increasing the difficulty by staying just under the coins necessary to do so. However, even during CBs when not enough coins are produced, the Coin-Hours and coins are still recorded so that a maximum number of coins can be created before changing the difficulty.

Maximum Coins Before Difficulty Change = # of Coins Minted in Last 10 CCPs / 10 * 1.5

To determine the increase in processing power, it is simply a matter dividing the number of coins by the Coin-Hours to get the number of hours it took for an average computer to make one coin, then compare it to the previous CCP. The increase in this power is determined with a simple formula:

Processing Power Increase = (Previous CCP Coin-Hours / Previous CCP Coins) / (Current CCP Coin-Hours / Current CCP Coins)

If this number is less than one, one is used so that the difficulty can never go down. To avoid intentional, large increases in difficulty as an attack on the network, a weighted system based on the last 9 difficulty increases is used as follows (with example increases):

Oldest (10th-9th) CCP weight: 0.05 x 1.06 increase (0.053)
9th-8th CCP weight: 0.05 x 1.09 (0.0545)
8th-7th: 0.05 x 1.04 (0.052)
7th-6th: 0.05 x 1.00 (0.05)
6th-5th: 0.10 x 1.08 (0.108)
5th-4th: 0.10 x 1.07 (0.107)
4th-3rd: 0.10 x 1.03 (0.103)
3rd-2nd: 0.20 x 1.07 (0.214)
2nd-current: 0.30 x 1.25 (0.375)

A very large increase was used as the last amount to show what might happen if someone were to attack the difficulty of the Network: a 1.1165 final number, or an 11.7% increase in difficulty. Unless this attack is sustained, the difficulty will not increase for some time afterwards.



The difficulty attack will probably go in a separate section, but there it is for an example. At bitcoin's estimated $10,000 cost to run per day, this attack would require $300,000 of electricity just to equal the network, so whatever increase it was trying to achieve would be cut in half unless it does more than half the network, then it would only be weighted 30% (perhaps less, first run of numbers). Much of the coins would be distributed to other people in the same Net, so most of that electricity is lost too.
hero member
Activity: 798
Merit: 1000
October 11, 2011, 12:46:30 PM
I wasn't trying to tie it to the dollar per se, that was just an example for the initial stabilization phase. The coin's price will essentially be tied to the global average electricity cost. So if global electricity suddenly got 10% cheaper (eg. new invention) all coins will lose 10% of their value and be worth, for example, 90 cents each (and vice-versa). I find that a very reasonable drawback though, not to mention unavoidable. But if the fed prints a trillion dollars tomorrow that will make the dollar cheaper, so it'll cost people more cents per Kilowatt worldwide, so the coins remain essentially unchanged.

I'm proposing that it is avoidable in the newest version of my proposal. Smiley

Quote
But who will the merchants pay their money for to acquire bitcoin credit?

Not sure what you mean. By putting their money on the line, I mean they must maintain a certain balance in their account to get transaction fees refunded. It is basically security against approving bad spends. The penalty for attempting to subvert the network is losing whatever balance you have.

Quote
How will it be decentralized? My suggestion keeps everything in the current design intact except for the number of coins each new block will contain. That's why I believe it requires very simple modification to the current code, plus it will be just as familiar to the existing audience.

It will be less decentralized in that each node in the network is aware of what other nodes are approving transactions. It will be less anonymous in that nodes that are approving transactions will have to sign those transactions. But these trade-offs mean that the network does not rely on hashing power and it will ultimately be far more scalable and far more adjustable than bitcoin. The endgame for bitcoin is that bank-like entities will be running the show as regular nodes have no hope of actually being a part of the network (8Gb/s bandwidth, a terabyte of space every few days). It puts the power back into the hands of the elite.

Not to mention that any direct competitor to bitcoin that is forked from bitcoin is going to have the major issue of 51% attacks on the network. See fairbrix, SC2, namecoin, etc.
member
Activity: 97
Merit: 11
October 11, 2011, 07:32:46 AM
I haven't read the whole thread, but it appears you want to stabilize the price of a bitcoin with the dollar, based on the estimated number of CPUs mining. This has 3 major problems, imo: 1) it doesn't protect against dollar inflation (which isn't terrible, but if the fed prints more dollars so does bitcoin), 2) estimating the number of CPUs is difficult if not impossible with the bitcoin proof-of-work design, 3) the security/continuity/dependability of the network still relies on massive amounts of hashing power, and always will. Bitcoin also has terrible scalability issues.
I wasn't trying to tie it to the dollar per se, that was just an example for the initial stabilization phase. The coin's price will essentially be tied to the global average electricity cost. So if global electricity suddenly got 10% cheaper (eg. new invention) all coins will lose 10% of their value and be worth, for example, 90 cents each (and vice-versa). I find that a very reasonable drawback though, not to mention unavoidable. But if the fed prints a trillion dollars tomorrow that will make the dollar cheaper, so it'll cost people more cents per Kilowatt worldwide, so the coins remain essentially unchanged.

Although it's not in the proposal yet, I did mention somewhere in this thread I came up with a very reasonable solution to not require hashing power at all: let merchants put their money on the line to secure the network, and in return, refund most or all of their mandatory transaction fees. So if the economy is completely stable, no hashing power is necessary.
But who will the merchants pay their money for to acquire bitcoin credit? How will it be decentralized? My suggestion keeps everything in the current design intact except for the number of coins each new block will contain. That's why I believe it requires very simple modification to the current code, plus it will be just as familiar to the existing audience.
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 02:51:08 PM
SC2 is using a method of trusted peers which also prevents 51% attacks. Might wanna look into it. Bitcoin implementation is a joke that was not thought out properly by them Japanese scammers.

I'm just curious. Do you have a link? I'm searching the solidcointalk.org board and I see that claim. But I can't seem to find an explanation.
hero member
Activity: 518
Merit: 500
October 09, 2011, 02:09:17 PM
Some of it could be applied, sure, but certainly not all of it. Bitcoin is secured by hashing power. This is a joke that needs to be eliminated.

I agree with you here as well. Any idea I would propose would contain a smaller "trusted" core of peers with the basic characteristics you designed into your "TrustNet/FreeNet/CoreNet" entity. I just think it could simplify the (transaction union/reconciliation procedure) that you go through in creating Primary Blocks.

I've spent too much time thinking how to get away from how bitcoin works, so no offense, but I'm not spending any effort on trying to figure out how to hack the encoin idea in.

Fair enough!

SC2 is using a method of trusted peers which also prevents 51% attacks. Might wanna look into it. Bitcoin implementation is a joke that was not thought out properly by them Japanese scammers.
hero member
Activity: 798
Merit: 1000
October 09, 2011, 02:07:38 PM
"If the award lowers over time" makes it sound like, you still entertaining other concepts besides adjusting awards & difficulty towards Koomey's law? Are you considering another alternative.

Well, I'm still speculating here. I don't have anything set in stone.
We can't assume koomey's law will hold, so we have to let the market figure it out.
To account for Moore's Law, I believe the difficulty should adjust every 25k coins (up for debate) based on coin-hours. Coin-hours = # of users in a block * # hours between blocks. Though I haven't released proposal 4.0 obviously, this can be determined correctly based on the way my new design for freenets/corenets will work. People won't be able to just join or leave willy-nilly.

Then, to account for Koomey's Law, the award will adjust every 250k coins (up for debate). How the award will adjust I'm not sure yet. It can't be from 6->3 because that will just bring in the reign of FPGAs and kill GPUs. So I'm thinking from 6->4.5->3->6 or 6->5->4->3->6 (probably this). If it goes too fast, we are likely to give low wattage high efficiency miners an even bigger advantage by making GPUs totally unprofitable way before their time--thus killing the supply and causing a permanent increase in the CTP before its time. So "on occasion" is sort of referring to the fact that when it happens is not very predictable. "if it lowers over time" is just me speculating on how this scenario would work.

Perhaps # of coins shouldn't be the only factor though, because if ENC explodes in popularity, 250k coins could go pretty fast. Then again, I dunno, because people might just be mining like mad because the CTP is much lower than 1 ENC. So perhaps it has to stay rigid. Then again, perhaps the change in award could be based on how long it took to get there.

All this is assuming that the difficulty never goes down which I think needs to be part of the plan. Difficulty is based on coin-hours, not amount of computing power, so I really don't think it should be an issue unless someone is trying to grief the system or intentionally make coins cost more to produce so their existing hoard is worth more. To do it will cost them a lot of money, but I'm trying to think of the far-future.
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 02:04:00 PM
Some of it could be applied, sure, but certainly not all of it. Bitcoin is secured by hashing power. This is a joke that needs to be eliminated.

I agree with you here as well. Any idea I would propose would contain a smaller "trusted" core of peers with the basic characteristics you designed into your "TrustNet/FreeNet/CoreNet" entity. I just think it could simplify the (transaction union/reconciliation procedure) that you go through in creating Primary Blocks.

I've spent too much time thinking how to get away from how bitcoin works, so no offense, but I'm not spending any effort on trying to figure out how to hack the encoin idea in.

Fair enough!
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 01:45:48 PM
I think we are in, what an old professor of mine used to call, violent agreement. I think we are saying very much the same thing, but using different words. Inflation for one tends to be a maddening word for me. Normally I use it to mean goods prices are inflated against ENC. Meaning bread used to cost 1 ENC and now bread costs 2 ENC. But talking about buying and selling ENC using dollars the terms get more complicated.

In my mind if,
before: 1 ENC = 1 loaf = $1
after: 1 ENC = 1 loaf = $2   Then we are stable and have met our goals
after: 1 ENC = 2 loaf = $2   Then goods pricing, with respect to ENC, has deflated. Meaning mint more coins. Discourage hoarding.
after: 1 ENC = 1/2 loaf = $1  Then goods pricing, with respect to ENC, has inflated. Meaning destroy coins. Encourage hoarding.

But I think we are both pushing in the same direction, no matter what definitions we are using. So much so, that if I didn't reply to something in the previous post, assume we are in agreement.

Right, this is why the award would gradually (or perhaps not so gradually) lower on occasion, to weed out the less efficient.

I agree with everything in that section, but I'm confused by your use of "lower on occasion".

Wasn't the plan to lower deterministically (and smoothly) based upon the presumption that Koomey's law will hold? I think that is what you are saying. If so, I agree.

But on first read "on occasion" sounded like, "If things get wonky..." 

If the award lowers over time, people have to adjust their output or risk making coins unprofitable. This is kind of annoying because people who want to go full blast still can (supercomputer/pool problem). Certainly the software can automatically adjust when the award changes, but each time every person will have to look at their mhash compared to their watts compared to the market price to see if what they are doing is profitable (going full blast is likely going to subsidize others as described before). But I think this is the only way to do it and really let the market decide. 1 ENC tends to 1 ENC.

If you mean, "When the award lowers over time" then I totally agree with the rest of your statement. As far as I have been able to figure, people are required to pay attention and make decisions in their own self interest. Otherwise, they pay their own consequences with the electric company. (Like a gambler losing in Vegas)

However, THE GENIUS OF YOUR ENC=KWH IDEA means nobody else has to care.

If the award reduction/difficulty increase keeps everyone else aligned with Koomey's law. (for argument 1 ENC = 10 kwh) Then the run away minter is now minting at 1 ENC = 11 kwh. If he continues to do so causing an ENC glut and price inflation then he is compounding his loss because his 1 ENC buys < $1.

If enough people mint at a loss, it will temporarily trick the system into thinking the consensus is to add more money into circulation. Your proposed fee refund will begin dumping money into the market. This will temporarily increase inflation for the minter, but your "interest" compensates everyone else as an offset. This further compounds the runaway minter's losses.

But there is no way a runaway minter can profit. Like in Vegas, a time will come when he has to pay the piper. And that electric company piper is a real bitch!

---

"If the award lowers over time" makes it sound like, you still entertaining other concepts besides adjusting awards & difficulty towards Koomey's law? Are you considering another alternative.
hero member
Activity: 518
Merit: 500
October 09, 2011, 12:38:09 PM
Me too!

I think it might be possible to implement this economic model on top of the bitcoin code base. I'm kicking around in my head if the reconciliation/consensus stuff could be avoided by using varying speed block creation.

Someone wrote GeistGeld was experimenting with 15 second block creation times? I think the feasibility of that depends on how many peer nodes they have in the network. But if they could substantially speed up the rate without overwhelming the network, then their appears plenty of room for flexible block creation rates.

Some of it could be applied, sure, but certainly not all of it. Bitcoin is secured by hashing power. This is a joke that needs to be eliminated. I've spent too much time thinking how to get away from how bitcoin works, so no offense, but I'm not spending any effort on trying to figure out how to hack the encoin idea in.

Agree with you there mate !
hero member
Activity: 798
Merit: 1000
October 09, 2011, 12:26:03 PM
Me too!

I think it might be possible to implement this economic model on top of the bitcoin code base. I'm kicking around in my head if the reconciliation/consensus stuff could be avoided by using varying speed block creation.

Someone wrote GeistGeld was experimenting with 15 second block creation times? I think the feasibility of that depends on how many peer nodes they have in the network. But if they could substantially speed up the rate without overwhelming the network, then their appears plenty of room for flexible block creation rates.

Some of it could be applied, sure, but certainly not all of it. Bitcoin is secured by hashing power. This is a joke that needs to be eliminated. I've spent too much time thinking how to get away from how bitcoin works, so no offense, but I'm not spending any effort on trying to figure out how to hack the encoin idea in.
hero member
Activity: 798
Merit: 1000
October 09, 2011, 12:18:46 PM
The hardest thing about monetary policy is that you are optimizing against a hidden variable. Nobody really knows what the break even point is for ENC. Once you have a $/ENC exchange, individual decisions becomes easier (I know what my cost, and immediate return would be). But still if you wanted to know what the system's optimal ENC price should be, there are too many hidden variables to get an accurate calculation.

Right, this is why the award would gradually (or perhaps not so gradually) lower on occasion, to weed out the less efficient.
If FPGAs or low-wattage GPUs become prevalent, these devices are making coins at a lower cost to produce than previously possible.
If the award is dramatically lowered to 3 instead of 6 coins, inefficient cards have to lower their output while efficient cards can remain at the same output (assuming they use about half the electricity). This provides a new baseline that I mentioned. Inefficient cards will have to quit, and efficient cards will have to compete against each other instead of siphoning off the inefficient cards. Then, after a period of time, the award and difficulty can double back to 6 so that the process can start over.

Since, in a stable economy, coins may not need to be produced all that much, I came up with the idea of doing this by the number of coins produced rather than time. Perhaps the award could adjust every 250k coins or something.

But this provides a potential attack. Supercomputers and/or pools could get in and intentionally raise the difficulty if not too many people are making coins. This could be alleviated by having a minimum amount of time before producing a block and having a maximum difficulty increase per chunk of coins produced (this figure will be hard to determine though because we have both Moore's and Koomey's Laws we need to account for). It's a band-aid though. Intentionally raising the difficulty means the coins would start trading for more than their CTP, and this gives an opportunity for hoarders to make a lot of money. So it might encourage them to raise this difficulty. That's why I'm thinking a bigger chunk like 250k coins, it would cost a lot of money to do it. But by making it so high, this means that coins may be produced for a long time at less than the CTP, but at least there is a cap on it.

Quote
I'm pretty sure you are working on the same detection issues. It sounds like you are detecting money supply is "too low" by how many coins are minted. Or perhaps a ratio of minted coins/traded coins over a fixed period. Your money supply is "too high" as that ratio tends toward zero.

Not trying to detect anything; trying to foster competition among the more efficient so that it can happen automatically.

Quote
Psychologically, I suggest charging your *panic* fee ON TOP OF the price the seller is asking. As opposed to requiring the seller to hide that included fee in his price. The former tends to make clear to *panicked* buyers that prices are *already* considered too high. It also makes it clear to sellers that NOW is a great time to actually close the deal. The later tends to encourage sellers to inflate their prices (which is what we are fighting against). And if they think prices are moving higher, they are further encouraged to hoard goods.

I think if you encourage hoarders to hoard during inflation (via interest), this works itself out. As I said, new buyers won't care if prices are inflated because they paid less for their coins. If 1 ENC costs 0.5 ENC from a year ago, they have no issue with paying 2 ENC for a loaf of bread. They shouldn't be penalized for buying in during inflation. It sounds like you are trying to prevent an inflationary spiral which I think is awfully unlikely with the monetary policy. No one is going to make coins during inflation, so the economy should eventually recover, so this will encourage people to buy coins and remove them from circulation.

Quote
As this ration tends above 1, your fixed transaction fee tends to fight against your monetary policy goals. You are destroying coins during a period where everyone is in agreement that more coins need to be minted. The consequences of this should be minimized whenever possible.

But they are minimized. Merchants will be providing a service to the network by confirming transactions and so on, and in doing so they are receiving a large chunk of these transaction fees back. Hoarders receive a small interest payment and this payment could be used to sell on the market. May as well sell now before the coins get back to CTP.

Quote
This is a good time to re-distribute all fees. Both the system's previously hoarded fees, AND the current transactions fees. Who receives those re-distributed fee coins is NOT a monetary policy decision. It can be adjusted to encourage other behaviors as you see fit.

I think it is more fair to go to the hoarders as they are people who already believe in the system. Distributing these fees to miners only encourages more people to mine when the price is high, sell, and be done with it.

Quote
Say perhaps, the number of coins awarded per block is in proportion to (total minted/trading fees). Does that tend toward stabilization or toward more dynamic swings?

I think it is just too hard to predict what will happen by doing this.

If the award lowers over time, people have to adjust their output or risk making coins unprofitable. This is kind of annoying because people who want to go full blast still can (supercomputer/pool problem). Certainly the software can automatically adjust when the award changes, but each time every person will have to look at their mhash compared to their watts compared to the market price to see if what they are doing is profitable (going full blast is likely going to subsidize others as described before). But I think this is the only way to do it and really let the market decide. 1 ENC tends to 1 ENC.

If prices of electricity increase faster than fiat inflation, people will have to wait until more efficient hardware can catch up. In the mean time, hoarders will have the opportunity to smooth out deflation by selling. They will make a profit, but not by their "early" investing, just by an unpredictable consequence of the world.

If fiat inflation increases faster than the price of electricity, there will be more competition to make coins and this will cause the difficulty to go up and the market price to go up, as it should.

If the price of electricity falls or hardware becomes more efficient faster than expected, the lowering of the award causes renewed competition that will increase the difficulty faster than normal (it's profitable for me to mint at full blast, so I will).

The *only* problem I see is, like I said, someone with the time and the means to intentionally try to drive up prices. If there are always people minting it is a lot less easy to do, but during times of inflation it would be even easier to accomplish. I'm not sure how to safely account for this yet.
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 11:57:44 AM
I think I've fricken solved it. Tongue

Me too!

I think it might be possible to implement this economic model on top of the bitcoin code base. I'm kicking around in my head if the reconciliation/consensus stuff could be avoided by using varying speed block creation.

Someone wrote GeistGeld was experimenting with 15 second block creation times? I think the feasibility of that depends on how many peer nodes they have in the network. But if they could substantially speed up the rate without overwhelming the network, then their appears plenty of room for flexible block creation rates.
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 11:13:30 AM
Can you at least give us an ETA for this please  Roll Eyes

No, because this is not a trivia: Take bitcoin's code base, change one constant, recompile and offer a release. At least we haven't figure out if it could be done that way yet. Some ideas actually take work.

I'll keep working on this until we can simplify the idea into something easy to implement. If that becomes the case, I'll just do it. But if the minimal implementation is going to take several man years of coding, I can't commit that much time and energy for free.

Eitherway the work would go so much faster if you would send in that $8,000 already!
hero member
Activity: 518
Merit: 500
October 09, 2011, 11:04:33 AM
Can you at least give us an ETA for this please  Roll Eyes
Red
full member
Activity: 210
Merit: 115
October 09, 2011, 11:01:51 AM
I'm pretty sure I'm in general agreement with you. Not sure I understand all the mechanisms you have for paying interest. But I agree you are pushing the system in the right direction.

The hardest thing about monetary policy is that you are optimizing against a hidden variable. Nobody really knows what the break even point is for ENC. Once you have a $/ENC exchange, individual decisions becomes easier (I know what my cost, and immediate return would be). But still if you wanted to know what the system's optimal ENC price should be, there are too many hidden variables to get an accurate calculation.

That's what led me to try and detect what the "human" consensus on the money supply was (too high, just right, too low). Technically, I think you could get away with detecting just two states (too high, too low). In that case the stable (just right) state would be when the system was oscillating between too high and too low. However, in my personal analysis, I always tend to think about the optimal stable state first. Then I look at how the other two differ from optimal.

I'm pretty sure you are working on the same detection issues. It sounds like you are detecting money supply is "too low" by how many coins are minted. Or perhaps a ratio of minted coins/traded coins over a fixed period. Your money supply is "too high" as that ratio tends toward zero.

I'd like to propose is ratio for discussion. (minted coins/trading fees) Where minted coins is the total number of minted coins in a given period.  Trading fees is the total number of destroyed coins in the above period. Meaning total number of traded coins times whatever fixed fee you decide on.

(total minted/trading fees) < 1
If this ratio is zero, there is a 100% consensus that there is too much money currently available for circulation.
In this situation, I propose you attempt to do two things.
1. Encourage potential buyers NOT to buy. (Hoard coins until prices recover)
2. Destroy the coins of panicking actual buyers. (Your coin destroying fee)
3. Encourage potential sellers to sell NOW! (Stop hoarding goods)

Psychologically, I suggest charging your *panic* fee ON TOP OF the price the seller is asking. As opposed to requiring the seller to hide that included fee in his price. The former tends to make clear to *panicked* buyers that prices are *already* considered too high. It also makes it clear to sellers that NOW is a great time to actually close the deal. The later tends to encourage sellers to inflate their prices (which is what we are fighting against). And if they think prices are moving higher, they are further encouraged to hoard goods.

I think you are saying, "Instead of actually destroying these coins, they go into a system managed hoard for later re-distribution." If that is what you are saying, then I agree. Hoarding those coins is monetarily indistinguishable from destroying them.


(total minted/trading fees) = 1
If you are minting exactly what it take to replace your fees then there is a 100% consensus that the money supply is "just right".
Who should receive the newly minted coins is NOT a monetary policy decision. It can be adjusted to encourage other behaviors as you see fit.


(total minted/trading fees) > 1
This ratio is unbounded, so it has no way to express 100% consensus that the money supply is "too low". But the farther this ration moves above one, the closer you get to that consensus.
In this situation, you have too many goods trading for the existing amount of coins. So I propose you attempt to do two things.
1. Encourage, hesitant buyers to buy NOW! (Stop hoarding coins)
2. Discourage sellers from panicked selling of goods. (Hoard goods)

As this ration tends above 1, your fixed transaction fee tends to fight against your monetary policy goals. You are destroying coins during a period where everyone is in agreement that more coins need to be minted. The consequences of this should be minimized whenever possible.

This is a good time to re-distribute all fees. Both the system's previously hoarded fees, AND the current transactions fees. Who receives those re-distributed fee coins is NOT a monetary policy decision. It can be adjusted to encourage other behaviors as you see fit.


Merchants get whatever fees that they can back based on how much money they are willing to put on the line. Anyone else just loses their fees. These lost fees get redistributed to people hoarding currency. So in down times, instead of selling, people can hoard and earn interest on those who do sell or trade at inflated prices. No one who buys cheap is going to care that they're getting inflated goods, only people who saved would care. So instead of freaking out, savers can just sit back, earn interest, and wait for the economy to get back.

I think I'm generally agreeing with this, as stated above.

And as an addendum to the other stuff, instead of basing the ENC reduction on time, we could do it based on the number of coins produced. This means if we get to a period where things are too cheap, it will last a shorter amount of time while ENC gets to a new baseline. HOLY SHIT.

I'm not sure I understand this enough to comment.

EDIT: LMAO, I really didn't understand what you meant when I started typing below. (Basing ENC reduction on time.) I thought you were talking about the logarithmic reduction to compensate for increasing CPU efficiency. Now that I read what I wrote, and re-read what you suggested. It seems like I just re-wrote exactly what you said. If that is the case, I guess I do understand it enough to comment!


But I wrestled with a similar sounding conundrum:
If (total minted/trading fees) greater than one, persists for multiple periods in a row. It seem like coins should be easier to mint. That is what I was getting at when I added the +2 level to my system.
If (total minted/trading fees) less than one, persists for multiple periods in a row. It seem like fees should be higher. However, both of these lead to more abrupt final transition states.

I hadn't considered the above ration when I was thinking about that though. Perhaps things could be smoothed by considering the ratio rather than time? [edit: Smiley]

Say perhaps, the number of coins awarded per block is in proportion to (total minted/trading fees). Does that tend toward stabilization or toward more dynamic swings?

Fee's are more difficult to adjust because they affect the ratio itself. But you could add a "surcharge" as the ratio moved below one toward zero. Perhaps a surcharge using the inverse ratio (trading fees/total minted) makes sense. (As minting moves to zero, the surcharge moves to infinity.) That would provide a strong disincentive to panicked selling!
hero member
Activity: 518
Merit: 500
October 08, 2011, 03:01:29 PM
Quote
I think I've fricken solved it. Tongue

OK now get coding and send me over 10 000 coins please. Thanks !!!
hero member
Activity: 798
Merit: 1000
October 08, 2011, 02:59:06 PM
I have so many different versions in my head right now. I would have to read your latest on fee and interest to be able to respond coherently. I know anything I say right now would sound hopelessly lost in the weeds.

Merchants get whatever fees that they can back based on how much money they are willing to put on the line. Anyone else just loses their fees. These lost fees get redistributed to people hoarding currency. So in down times, instead of selling, people can hoard and earn interest on those who do sell or trade at inflated prices. No one who buys cheap is going to care that they're getting inflated goods, only people who saved would care. So instead of freaking out, savers can just sit back, earn interest, and wait for the economy to get back.

And as an addendum to the other stuff, instead of basing the ENC reduction on time, we could do it based on the number of coins produced. This means if we get to a period where things are too cheap, it will last a shorter amount of time while ENC gets to a new baseline. HOLY SHIT.

I think I've fricken solved it. Tongue
Red
full member
Activity: 210
Merit: 115
October 08, 2011, 02:54:20 PM
What do you think about my post on giving interest?

I have so many different versions in my head right now. I would have to read your latest on fee and interest to be able to respond coherently. I know anything I say right now would sound hopelessly lost in the weeds.
hero member
Activity: 518
Merit: 500
October 08, 2011, 02:53:56 PM
Please just get this started already. Too much thinking no doing around here.

Cannot wait to buy 10 000 EnCoins then dump them ASAP as price rises. Please hurry up ! Thanks !

I'll sell you 10,000 now from the initial pre-mine. Just send $10,000 to... Wait, you are right. You deserve a pre-adopter discount so you can get some serious return on your investment. Just send $8,000 to me!

Maybe more like 8 cents !
Pages:
Jump to: