[ANNOUNCE] The Proposal for EnCoin

[Etlase2]

"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.

[1713283750]

1713283750

[1713283750]

1713283750

[1713283750]

1713283750

[bulanula]

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.

[Red]

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.

[Suggester]

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.

[Etlase2]

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.

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.

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.

[Etlase2]

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.

[Etlase2]

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.