Bitcoin Forum
November 16, 2024, 06:58:28 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Encoin scrutiny  (Read 1341 times)
MoneyIsDebt (OP)
Hero Member
*****
Offline Offline

Activity: 642
Merit: 500



View Profile
April 15, 2012, 03:30:28 PM
 #1

I'm opening a thread here to discuss the Encoin proposal - to clarify uncertainties, and get more details out, as well as to open a discussion so we can find flaws and solutions before getting deep into the implementation.

I'll start off with a couple of questions:

1) Will I when I receive a payment in Encoin, be able to see who sent the payment? Or will I have to deal with generating a new address every time, as with bitcoin? Anonymity is nice, but not always necessary. If I'm paying a bill, I want to make it loud and clear, at least to the recipient, that I did in fact pay.

2) Is the mechanisms in Encoin meant to keep the cost of production of a coin stable, or the actual market price / value stable?  If the first, why does that matter? If the latter, how?
Etlase2
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
April 15, 2012, 05:03:49 PM
Last edit: May 29, 2012, 05:31:27 PM by Etlase2
 #2

Latest encoin thread for reference: https://bitcointalk.org/index.php?topic=49683.0

Before I start, bear in mind that the wiki is now like 5 months old and I have made many mental and electronic notes that have never gotten to the wiki. The design has evolved frequently and after I wrote the wiki, not enough interest was drummed up at the time for me to really bother updating it.

1) Though it's buried a bit, the transaction page is here. Users have the option of using the system similarly to bitcoin with separate addresses for each transaction. However, this comes with a big caveat that each transaction requires the minimum transaction fee--which is notably higher than bitcoin's currently, however in the future when mining rewards drop out, they would probably be equivalent. So if you believe that pseudonymity is something worthwhile, you will be nickeled a bit more than you would in bitcoin.

With that said, at least under the written wiki implementation, there would be an 8-byte miscellaneous field which could and should be used by everyone to hash a receipt of the transaction (or simply an order number) so that there is both proof of what the transaction is for (but only if you have a copy of the receipt) and transaction identification to the receiver. This means that the receiver does not need a different receiving address to keep track of each incoming transaction.

2) It is likely to be a combination of both.

Cost of production can change significantly in a number of ways:
A) Energy prices drop significantly
B) Computing hardware makes a giant leap
C) SHA256 or whichever algorithm that is used has a weakness that is exploited (and/or QC)

A1) In some form or another, Koomey's Law will be a part of the coin creation system. This will account for decreasing energy prices over time by increasing the length of time required to produce coins.
B1) This is covered mostly by Moore's Law, but also by Koomey's Law in the case of very energy efficient hardware such as FPGAs or ASICs or future drops in energy consumption of computer hardware.
C1) Any far-reaching effects of this will be mitigated by free coins. Although I have significantly revised the free coins idea since that forum post.

All 3 effects are mitigated by free coins. All 3 effects will be mitigated by many additional ideas I have come up with since that limit how easy it is to create coins for one person. These are details I'd rather go into a bit later, but for example: first of all, the whole supplynet group thing is gone; joining the supplynet will require a minimum difficulty solution and as more peers join this difficulty may rise; once joined, each wallet can create up to 2 coins before being forced to join again; a minimum pool of peers must be in the supplynet before mining can begin based on how many are in the tradenet; only a fraction of those in the pool will be able to create coins at any one time (probably 25%), with new peers selected at random as coins are produced; a maximum amount of coins may be produced per coin-creation period (defined in the wiki, but it will be much different) based on a hard-coded minimum or the average amount of transaction fees in prior periods.

YES I just listed a whole bunch of stuff that sounds complex. But the goal is to have the network adapt to a changing world without the need for developer intervention.


Now, "market price" will not be stable long-term as long as regular fiat money continues to inflate the way it does. "Value" may not be stable on a per-coin basis because of changes in cost of production. However, the basic bootstrap design as far as coins go that I have so far is this:

Years 1-3: Coin reward for solving a block is 3-6x the normal value, starting with 6, and gradually dropping to 3 over the 3 years. This is to get relatively cheap coins into the economy without a significant electrical cost.
Years 4-6: Coin reward is 1x. Allows time for demand to build and distribute coins around.
Years 7-9: Coin reward is 1x, but another 1x those coins is added to account balances proportionally, and another 1x of those coins is awarded randomly to those who send/receive transactions.
Years 10+: Coin reward is 1x, but 2x is awarded to existing balances and 2x to trades. This means that some change would have to happen very quickly that made coins more than 5x easier to produce for it to even really affect the economy. Even then, it would have to be widespread (likely only a SHA2 weakness), and if it is widespread, moore's law will account for it after a few coin-creation periods.

SO, the value may not be stable on a per-coin basis, but coins will be added to all accounts. I'm trying to come up with a percentage based system for adding new money to existing accounts in the case of a serious ramp up in coin production. The worst that could happen by over-awarding existing balances is that the value per coin drops and mining stops, but the value in each account remains the same. Although it does make things a little tricky when it comes to contracts, loans, wages, etc. so I would like to keep the per-coin value as stable as possible.

Not only do I hope to keep a relatively stable value, but also require the absolute minimum in electricity waste.

MoneyIsDebt (OP)
Hero Member
*****
Offline Offline

Activity: 642
Merit: 500



View Profile
April 17, 2012, 10:48:02 AM
 #3

Thanks for the answers so far!

Quote
with new peers selected at random as coins are produced

A few times (in the wiki, and once in your answer) there are mentions of "picking randomly among peers". From an implementation standpoint, how would this be feasible? How would I know which peers are trustworthy or not? If I don't know which peers are trusted, how can I pick among them?  Bitcoin solves this by the consensus of the blockchain and proof of work etc.

Also, who exactly gets to do the picking? In a p2p network - if each node picks randomly, they're not likely to pick the same peer.

(I'm asking a bit stupidly here on purpose - just that it needs to be clarified)
Etlase2
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
April 17, 2012, 11:08:02 AM
 #4

Each situation where a random peer needs to be picked will be slightly different, but I will give a possible example for this situation.

A SupplyNet peer completes a coin creation transaction. This transaction is (level 2) approved a few minutes later. I did not update the wiki about how level 2 works now, but I think I posted something in the v4 thread. Basically level 2 happens when 50% of the reputation has signed a transaction. So if there were 50 TradeNet groups, it would take approximately 250 seconds (10 seconds x 25 tngs) to level 2 approve a transaction, assuming the reputation is fairly evenly spread. Anyways, the hash of the transaction block in which the tx appeared will be used as a kind of seed modulo to determine from the remaining available peers whom is the next peer to be given a coin creation problem. This way everyone agrees or will eventually agree on who is the next peer. Every piece of randomness will always be based on information that everyone agrees on but can not be predicted in advance.

Any comments or questions on the stable value part?

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!