Bitcoin Forum
May 03, 2024, 11:30:20 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
Author Topic: [ANNOUNCE] EnCoin - An alternative with a completely different paradigm  (Read 12060 times)
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 05:00:52 AM
 #101

Bitcoin is fiat, just like dollars and euros and whatever else. Encoin is not.

There is no central issuer of Bitcoins, and Encoin doesn't exist.

take a gander at this and see if you can make it to the 1:30 mark and beyond:

http://www.youtube.com/watch?v=hx16a72j__8&feature=player_embedded

additionally, this is a lot to ask, but try to see if you can draw any parallels

1714735820
Hero Member
*
Offline Offline

Posts: 1714735820

View Profile Personal Message (Offline)

Ignore
1714735820
Reply with quote  #2

1714735820
Report to moderator
Whoever mines the block which ends up containing your transaction will get its fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 05:01:05 AM
Last edit: September 27, 2011, 05:33:26 AM by Red
 #102

I'm going to take one more shot at this. Your calling me back here has been fun. I want to thank you for that.

I understand what you are saying about: trust = hash * time vs. bitcoin's way. I don't think that is "trust" though. I think hash * time = "effort". I'd don't think I'd even call it "work" because I'm not sure anything is actually getting done for the effort.

I'm also absolutely sure you overstate the dangers to bitcoin accounting. In bitcoin if you gain 51% of the hash power and you want to delete a transaction that happened 5 blocks back, you basically have zero hope of accomplishing that. If you have 51% of the hash power you CANNOT generate a fake transaction. You also can't transfer money from one account to another. You can't even do more than stall a transaction with 51% probability.

The dangers you hypothesized for encoin were much harsher than those bitcoin is currently suffers from.

Quote
Both of these sentiments are somewhat naive. There is no central authority that says what being compliant is or what the rules are. A decentralized network has to agree on all sorts of different things with the potential for infiltrators/attackers to try throwing a wrench in the mix whenever they feel a dash of whimsy. Part of the decentralizing rules (a large part) are how to handle it when someone does decide to go rogue.

I'll let most of this slide, since I'm under a pseudonymous handle. But trust me, I have more P2P experience than you know.

The important part of my message is about compliance to the protocol. In bitcoin, even with 75% of the hashing power, you can't stick a transaction into a block if it won't pass the validation rules. Every other honest node will reject your block. Worse, they'll all know you are a liar. That is what compliance means.

If I have your previous PB balances and all of the new transactions for this period, you had better not try to give me a new PB with balances that don't match the known transactions. If you do, you sure as hell better be able to produce a valid transaction I'm missing that reconciles the differences. I don't give a flying fart if your (hash * time) effort is 100% and my effort is 0%. If the math doesn't work you are still lying. That is what compliance means.

For that matter, previous investment of time adds nothing to ones trustworthiness. Say, I take a copy of the bitcoin block chain and validate it. I am now equally as capable as any other node at spotting fraudulent activity. I've spend no time and generated not a single hash. But even if the 10 longest running nodes agree to accept a new block with an invalid transaction in it, I can still publicly call them faulty at best liars at worst. Compliance means agreeing with the specification, not with the majority.

My recourse to compliance violations is not to bend over and take it because others have 51% of an imaginary quantity. My recourse is to publish the data on this forum. Call you a liar. Call the authorities and start sending out press releases. That is what compliance means.

---

If the only digital currencies you've ever seen are bitcoin analogs, I know it maybe hard to understand that most digital currencies and money transfer services strive to not waste CPU cycles or electricity. Expending needless effort is simply not required to guarantee the validity of crypto-currency accounting.

If you changed bitcoin into a client server system with only a single bitcoin server doing the accounting, it would remain equally as trustworthy and secure as it is now. So long as everyone can download the server's history and validate the current state, there are simply very few ways for the server to cheat. If every client keeps track of the most recent couple of block hashes, then periodically checks to make sure they don't leave the chain, there is simply nothing the server can do while still remaining in compliance. Every false move is instantly detectable by even the simplest of client.

Never fail quietly! It's one of the most important rules of software design.

---

I can show you how to take bitcoin's current implementation, remove the proof-of-work nonsense, and turn it into P2P network of Trusted Servers as you described. In the process you'll lose none of bitcoin's current security. If you want to add back in constant kwh mining and transaction fees, to help sustain a stable monetary policy that's awesome!

If you want to add a complicated history of effort model to rationalize sharing the wealth, that's your own business (literally). It adds, however, neither security nor trust.

Quote
Quote
The locks should not be removed until the account owner presents himself to a trusted human and offers a believable explanation of how the situation happened honestly. 100% of the trusted humans must agree to remove the locks.
This is highly centralized and won't be a part of any P2P protocol. (except maybe ripple, hehe)

A while back there was a bitcoin hack where a trojan stole wallets and transfered money out of people's accounts. There is nothing in the rules of bitcoin that prohibits that. There is certainly nothing in the rules that enables anyone to reverse that. But the programmers changed the rules and rolled things back.

That is what "Trust" means.
johnj
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
September 27, 2011, 05:16:11 AM
 #103

Bitcoin is fiat, just like dollars and euros and whatever else. Encoin is not.

There is no central issuer of Bitcoins, and Encoin doesn't exist.

take a gander at this and see if you can make it to the 1:30 mark and beyond:

http://www.youtube.com/watch?v=hx16a72j__8&feature=player_embedded

additionally, this is a lot to ask, but try to see if you can draw any parallels

You know, such a snotty attitude isn't very becoming of someone who's trying to rally up support for a purely on-paper idea.

Good luck with your *coin.

1AeW7QK59HvEJwiyMztFH1ubWPSLLKx5ym
TradeHill Referral TH-R120549
Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 05:28:45 AM
 #104

take a gander at this and see if you can make it to the 1:30 mark and beyond:

In general I think the video was full of crap.

I do want to point out that if EnCoin is intended to have a stable value base. That makes it trivial to create money "out of nowhere" via lending. It's also simplifies creating fractional reserve banks. More money "out of nowhere". This is on top of the new mining currency created "out of nowhere".

Only bitcoin like currencies that aim for ever increasing coin value (price deflation) discourage this "out of nowhere" money. There is a thread called "lending at negative interest" or some such where I disprove that silly logic.
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 05:53:59 AM
Last edit: September 27, 2011, 06:39:09 AM by Etlase2
 #105

I'm going to take one more shot at this. Your calling me back here has been fun. I want to thank you for that.

I understand what you are saying about: trust = hash * time vs. bitcoin's way. I don't thing that is "trust" though. I think hash * time = "effort". I'd don't think I'd even call it "work" because I'm not sure anything is actually getting done for the effort.

First of all, money is being paid for the effort. I pointed out that it could cost $6 million to perform this attack against a network with a size comparable to bitcoin's. Certainly no big deal for a government, but it weeds out the script kiddies.

And you are forgetting the other half, that trust can be removed by consensus (via proof of breaking the rules). So all that money and time spent is for naught.

Quote
I'm also absolutely sure you overstate the dangers to bitcoin accounting. In bitcoin if you gain 51% of the hash power and you want to delete a transaction that happened 5 blocks back, you basically have zero hope of accomplishing that. If you have 51% of the hash power you CANNOT generate a fake transaction. You also can't transfer money from one account to another. You can't even do more than stall a transaction with 51% probability.

The dangers you hypothesized for encoin were much harsher than those bitcoin is currently suffers from.

This is what I said: This means, as long as the attacker feels like attacking, the network is interrupted and may be permanently damaged thereafter.

If this were an ongoing attack, transactions will eventually be dropped, confirmations could never be sure, and double spends would be permanent (this is the least likely of intents of an agency attacking bitcoin). Civil unrest ensues, nobody wants to mine anymore, bitcoin crashes--accomplishing exactly what the attack set out to do. It would only have to happen once to prove that bitcoin sucks and is unreliable.

I'd say the entire project going in the toilet is a pretty harsh outcome. But this generally isn't discussed, because double spending is much easier to chew because that will only affect someone else.

Now yes, what an attacker could do with encoin sounds a lot more disastrous, but you have to remember that the honest network is still chugging along with barely a chink in its armor. And clients will know that something is wrong with the network that they're connected to. And assuming the encoin network is on a scale that is big enough to be in the public eye, this would be big news. But I believe I mentioned somewhere in the proposal that IP addresses relating to trustnets would be in the trustnet blocks so that new users can find them. Well, if a user that was only connected to dishonest networks checks back to an older copy of the primary block, odds are pretty good they could find a working IP address to get back on the right network (plus any internally saved IPs). So the chances of a user being duped into this dead network are almost zero. And even if they are, anything that happens on that network has no effect whatsoever on the real network, so it is harmless. The bad network quickly becomes a ghost town.

Quote
I'll let most of this slide, since I'm under a pseudonymous handle. But trust me, I have more P2P experience than you know.

Well, you did remark that "That whole concept is STUPID and IRRESPONSIBLE." about a potential grief attack on the network. Because, like, nobody in the history of the internet has ever tried to fuck up someone else's good time.

Quote
The important part of my message is about compliance to the protocol. In bitcoin, even with 75% of the hashing power, you can't stick a transaction into a block if it won't pass the validation rules. Every other honest node will reject your block. Worse, they'll all know you are a liar. That is what compliance means.

If I have your previous PB balances and all of the new transactions for this period, you had better not try to give me a new PB with balances that don't match the known transactions. If you do, you sure as hell better be able to produce a valid transaction I'm missing that reconciles the differences. I don't give a flying fart if your (hash * time) effort is 100% and my effort is 0%. If the math doesn't work you are still lying. That is what compliance means.

Sure, that is what compliance means, but you are forgetting that this proposal is trying to encompass a future where there could be 2 or 3 thousand transactions per second. I don't know the exact byteage of a transaction in bitcoin, but with having to account for all the small pieces that make it up, it must be at least hundreds of bytes. Encoins don't have to worry about the history of each divisible coin, so they should be smaller. Regardless, at 200 bytes we're looking at 16.5GB of transaction data per day. Gonna take awhile to have every user that makes use of "the cloud" or bitcoin's pseudo-nonymous network to digest that information. So instead of requiring high-level network servers to be a trustnet, instead data will only be available on request. Because a regular user does not need to know every. single. transaction that comes through the network. It is of pitifully poor design if there is another way. I mean, I didn't set out to solve one or two specific set of problems here. Bitcoin has a future problem around data transfers, the solution is, essentially, "get a connection with 8gbit/s internet access" and this is for peers too! https://en.bitcoin.it/wiki/Scalability (note it says transactions are currently around 500 bytes so I was off there)

Quote
For that matter, previous investment of time adds nothing to ones trustworthiness. Say, I take a copy of the bitcoin block chain and validate it. I am now equally as capable as any other node at spotting fraudulent activity. I've spend no time and generated not a single hash. But even if the 10 longest running nodes agree to accept a new block with an invalid transaction in it, I can still publicly call them faulty at best liars at worst. Compliance means agreeing with the specification, not with the majority.

Dude, stop equating trust with interpersonal relationships. And stop ignoring the fact that gaining enough trust would cost millions of dollars in a reasonably sized network. And you are disregarding the fact that one node that knows the others are lying has no way to communicate this information to all the peers. Seriously.

Quote
My recourse to compliance violations is not to bend over and take it because others have 51% of an imaginary quantity. My recourse is to publish the data on this forum. Call you a liar. Call the authorities and start sending out press releases. That is what compliance means.

This is so ridiculous that I want to stop responding.

Quote
If the only digital currencies you've ever seen are bitcoin analogs, I know it maybe hard to understand that most digital currencies and money transfer services strive to not waste CPU cycles or electricity. Expending needless effort is simply not required to guarantee the validity of crypto-currency accounting.

If you changed bitcoin into a client server system with only a single bitcoin server doing the accounting, it would remain equally as trustworthy and secure as it is now. So long as everyone can download the server's history and validate the current state, there are simply very few ways for the server to cheat. If every client keeps track of the most recent couple of block hashes, then periodically checks to make sure they don't leave the chain, there is simply nothing the server can do while still remaining in compliance. Every false move is instantly detectable by even the simplest of client.

Yeah but there is that trivial matter of someone taking down the server and ruining everybody's fun.

Quote
I can show you how to take bitcoin's current implementation, remove the proof-of-work nonsense, and turn it into P2P network of Trusted Servers as you described. In the process you'll lose none of bitcoin's current security. If you want to add back in constant kwh mining and transaction fees, to help sustain a stable monetary policy that's awesome!

If you want to add a complicated history of effort model to rationalize sharing the wealth, that's your own business (literally). It adds, however, neither security nor trust.

Wow I do believe that someone has been insulted. But I'm not gonna be goaded.

Quote
A while back there was a bitcoin hack where a trojan stole wallets and transfered money out of people's accounts. There is nothing in the rules of bitcoin that prohibits that. There is certainly nothing in the rules that enables anyone to reverse that. But the programmers changed the rules and rolled things back.

That is what "Trust" means.

You are referring to a website that was hacked, not people's wallets. I see you don't have a good understanding of the bitcoin protocol and what it is trying to achieve. You are missing some very key points that I am emulating with my design, and completely missing where it diverges and for what reason. I have tried to explain, but you are not accepting or even refuting with sense, so I give up.

Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 06:08:08 AM
 #106

You know, such a snotty attitude isn't very becoming of someone who's trying to rally up support for a purely on-paper idea.

Good luck with your *coin.

Haha sorry, with all the other crap I thought you were JohnDoe, that's why my response was a bit terse.
But "bitcoin isn't fiat" is just another in a long line of fallacies.

from wikipedia

The term fiat money has been defined variously as:
any money declared by a government to be legal tender.[4]
state-issued money which is neither convertible by law to any other thing, nor fixed in value in terms of any objective standard.[5]
money without intrinsic value.[6][7]


Yes it might not be pigeonholed into the exact modern definition of being issued by a government, but the sentiment is the same. Instead of governments, it's early adopters that have the ability to "issue" new currency at will.

Minsc
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
September 27, 2011, 06:15:03 AM
 #107

There is no central issuer of Bitcoins

MtGox is pretty close.

1DcXvfJdeJch9uptKopte5XQarTtj5ZjpL
Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 08:06:32 AM
 #108

Yeah, I did feel like I was ranting a bit. ;-)

I feel like you are reading what I write as more critical than I mean it.
I totally support your goal of creating a stable EnCoin currency.
I'm not opposed to you or anyone else calling it "a service" and charging for its use. Discussing those goals, however, is not a priority for me.
I happen to like the client/server part of the idea. It reduces the number of peers that need to communicate.

I'm still totally baffled by a lot of the names you have chosen. I've been developing software for pushing 30 years now. I know naming things is often one of the hardest parts. The terms "Network Trust" and/or TrustNet have too many ambiguous meanings. As an outside observer I think you should split your discussion into its two separate senses.

1) A TrustNet is a plug compatible replacement for a mining pool. In this sense you have "partners" who participate in mining, invest electrical cash, and get rewarded. You might consider calling this feature a "partnership". As in "Anyone can start their own EnCoin partnership..."

2) A TrustNet is also service which is provided to "clients". You might consider the term "host" or perhaps "teller". Originally I thought, from the name, that each TrustNet was itself a client facing entity. Meaning, a client connected to his particular TrustNet to get his transactions processed. As in, "I'm going to my bank." That made the two seem more like a single concept.

However, later you explained that each "partner" serves as a "host" for clients. It is not clear to me that clients even know that TrustNets exist. Perhaps they see each individual node as fungible automatic "teller" machines and don't care to which bank it belongs.

Either way, this is the sense most closely related to "Trust" for me. A client *is required* to trust its teller, since the client can't validate its own transactions. In the previous sense, it's clear partners don't have implicit trust for other partners. Neither do partnerships trust other partnerships. Certainly TrustNets don't constitute a web of trust. Using the word "trust" seems to obfuscate everything.


You are referring to a website that was hacked, not people's wallets.
Well you caught me there! :-) As you know I gave up on bitcoin more than a year ago. I only know of that event from headlines. I was around, however, when the developers deliberately changed the bitcoin client to fork the block chain and rewrite history. It seems there was a bug, and non-compliant transactions had made their way into the block chain. The old clients would accept transactions from the new client, but the new would accept from the old. It was really interesting watching the new chain overtake the old and all the old nodes dumping their entire reality. It really gave me pause.

I see you have very little understanding of the bitcoin protocol and what it is trying to achieve.
Actually, I do. There are long threads discussing details with satoshi somewhere.

But you are missing some very key points that I am emulating with my design, and completely missing where it diverges and for what reason. I have tried to explain, but you are not accepting or even refuting with sense, so I give up.
I do understand them. I'm not trying to refute the fact that some of your ideas are better, safer, more efficient than bitcoin. They most certainly are.

I just think that my ideas are even better than yours! ;-) So there!

Quote
I can show you how to take bitcoin's current implementation, remove the proof-of-work nonsense, and turn it into P2P network of Trusted Servers as you described. In the process you'll lose none of bitcoin's current security. If you want to add back in constant kwh mining and transaction fees, to help sustain a stable monetary policy that's awesome!

If you want to add a complicated history of effort model to rationalize sharing the wealth, that's your own business (literally). It adds, however, neither security nor trust.

Wow I do believe that someone has been insulted. But I'm not gonna be goaded.

I was actually serious here. I think inside your sprawling confusing misnamed concept, is a much simple gem of an idea struggling to get out. :-)

Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 08:39:11 AM
 #109

Yeah, I did feel like I was ranting a bit. ;-)

I feel like you are reading what I write as more critical than I mean it.
I totally support your goal of creating a stable EnCoin currency.
I'm not opposed to you or anyone else calling it "a service" and charging for its use. Discussing those goals, however, is not a priority for me.
I happen to like the client/server part of the idea. It reduces the number of peers that need to communicate.

The "service" aspect is a large part of the economy and how it will operate. You want to know how the price will stay stable? Because of the price of the service and rewards geared towards making the population do what is necessary to keep the price stable.

Quote
I'm still totally baffled by a lot of the names you have chosen. I've been developing software for pushing 30 years now. I know naming things is often one of the hardest parts. The terms "Network Trust" and/or TrustNet have too many ambiguous meanings. As an outside observer I think you should split your discussion into its two separate senses.

second draft, whatever, it's in the works.

Quote
However, later you explained that each "partner" serves as a "host" for clients. It is not clear to me that clients even know that TrustNets exist. Perhaps they see each individual node as fungible automatic "teller" machines and don't care to which bank it belongs.

part of the problem is adding new ideas without going back and looking at everything as whole and re-writing to compensate.

Quote
Well you caught me there! :-) As you know I gave up on bitcoin more than a year ago. I only know of that event from headlines. I was around, however, when the developers deliberately changed the bitcoin client to fork the block chain and rewrite history. It seems there was a bug, and non-compliant transactions had made their way into the block chain. The old clients would accept transactions from the new client, but the new would accept from the old. It was really interesting watching the new chain overtake the old and all the old nodes dumping their entire reality. It really gave me pause.

Well I don't know the details on this so I can't really comment. I'm curious now though.

Quote
I was actually serious here. I think inside your sprawling confusing misnamed concept, is a much simple gem of an idea struggling to get out. :-)

I'm curious how you plan on awarding coins in the system without proof of work. Not saying it's impossible, just genuinely curious. Are we going back to a central server concept? Because that, unfortunately, doesn't interest me.
and "sharing the wealth" has absolutely nothing to do with what the system is trying to achieve. I'm trying to put together a quick qt app to see how some of the numbers could fudge together. I will host it up somewhere when I'm done.

Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 09:14:31 AM
 #110

I'm curious how you plan on awarding coins in the system without proof of work. Not saying it's impossible, just genuinely curious. Are we going back to a central server concept? Because that, unfortunately, doesn't interest me.
and "sharing the wealth" has absolutely nothing to do with what the system is trying to achieve. I'm trying to put together a quick qt app to see how some of the numbers could fudge together. I will host it up somewhere when I'm done.

I wrote down the concept here. I think it got lost in all my ranting. There is no central server concept. Fully distributed. It's not that I don't use proof-of-work, its that I don't require proof-of-work for security. That makes mining optional except when it is actually appropriate to create new coins. In price inflated times nobody has to mine.

For monetary policy, it's not important who gets the coins first. However, in this case we always know where they go next—To the exchange. In this system, new coins always enter circulation immediately. That gives them the most immediate effect on prices.

See the other post for the real answer. It's a winner take all thing for the miners, but its up to each to decide which accounts they put the money in.

---

Now this doesn't mean the server can't add a client transaction fee to benefit the partners. It doesn't affect monetary policy at all. There is also no reason that different hosts can't charge different fees. They could compete on price or service.
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 09:46:03 AM
 #111

I wrote down the concept here. I think it got lost in all my ranting. There is no central server concept. Fully distributed. It's not that I don't use proof-of-work, its that I don't require proof-of-work for security. That makes mining optional except when it is actually appropriate to create new coins. In price inflated times nobody has to mine.

"For the sake of discussion I'm going to propose a hybrid system that's like bitcoin, except that instead of using mining to add the next transaction block to the chain, it adds the block through consensus."

Can you say how that consensus is achieved? Because that's a big gap in logic to just assume everybody will agree with nothing to back it up. What if one node disagrees just to spite you? How do you guarantee every node gets every transaction? How are all of these nodes communicating? How do you know if you've even reached consensus without knowing how many nodes there are?

I mean you could basically copy everything I've said about TrustNets, but make it so that they only mine if they want to. Oh wait I've got that covered with the 1/10th or 1/20th cool down mode with the 1/8th or 1/16th reward to ensure that they keep on doing it. Yes, they're still mining, because they're actually gaining something from it. By what incentive do you plan on keeping these people around as trusted peers, or whatever you want to call whoever reaches the consensus? The goodness of their hearts? During a contraction, coins are worth less and people are probably cashing out because they're afraid. How many people can you encourage to weather the storm? How do you prevent an attack on the consensus?

"For this discussion, just pretend I can prove that it's a secure process."

that is a whole hell of a lot to pretend, considering it is the basis for a p2p currency

Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 04:48:32 PM
Last edit: September 27, 2011, 05:31:09 PM by Red
 #112

"For the sake of discussion I'm going to propose a hybrid system that's like bitcoin, except that instead of using mining to add the next transaction block to the chain, it adds the block through consensus."

The point of that post was to propose a mechanism for monetary policy adjustment. I not to talk about consensus. I was directly answering the question someone else asked. I didn't want discussion of monetary policy self-adjustment to get sidetracked.

But yes, if you wish, I can explain my algorithm for consensus building. It's not really necessary. You've already proposed yours is secure. For this conversation, on monetary policy, that's good enough for me.

I just don't understand your concepts well enough to say, "let me propose an encoin like system, except..." Had I done that, I would have obviously been talking out my ass. I have no idea why you made most of your design decisions. Like say, why you changed 10 minutes consensus periods to X hours. How each miner is benchmarked against kWh. Or how effort based new coin allocation attempts to affect monetary policy.

What I'd really like to hear is how the monetary dynamics of your proposal relate to what I wrote down. I know my expansions constants (1/2 & 2) are probably not right. But the post captures the gist of my dynamics. Maybe there are more incremental levels to increase generation speed. Maybe the rules for varying the difficulty are too aggressive. That's not important yet. If their are changed, the basic structure of what I wrote will remain the same.

What I'm trying to understand is to what value/function does this system converge: If a new ASIC is 100 times more efficient? If a big new vendor joins the network? If the price of electricity spikes? If in any situation, the value of coins tends either to zero or infinity, I know the algorithm is not stable.


On the other hand, I genuinely don't understand your dynamics. I have nothing to compare or contrast.

You said you vary each difficult like bitcoin does. I don't understand when, how or why this happens. Say someone's hardware is generating ENC a 10 kWh per coin with X khash, and someone else's at 5 kWh per coin with x khash. You certainly can't vary the hash difficulty as a shared constant and meet your goals? You must have deeper thoughts than that. Tell them to me.

You gave constants for coin creation that seem unrelated to the transaction fees. I don't understand why you chose those constants and why (as both are part of monetary policy decisions) they are unrelated. If they are place holders to be calculated later that's OK. I just genuinely don't understand yet.

To combat increases in hardware efficiency over time, you propose rotating algorithms. Rotating doesn't seem to work, because if someone is willing to build an ASIC they might as well keep it around for when rotation comes back. 4 algorithms, 4 ASICs. Run when appropriate.

Beyond that, your concept seems to require competing engineers. Who decides if existing hardware is too efficient? Who gets to choose the next proof-of-work algorithm? How do you make everyone else adopt those new rules? That seems like a different kind of consensus building completely unrelated to your TrustNets.

---

I'm genuinely interested in understanding how your system meets its monetary policy goals. To me, all the other bits are optimizations to previously solved problems. They are interesting in their own right. I'm just interested in monetary policy first.
Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 06:04:08 PM
 #113

By what incentive do you plan on keeping these people around as trusted peers, or whatever you want to call whoever reaches the consensus? The goodness of their hearts? During a contraction, coins are worth less and people are probably cashing out because they're afraid. How many people can you encourage to weather the storm? How do you prevent an attack on the consensus?

I'm pretty sure satoshi covered this in his original white paper. On fortunately it tends to get overlooked with everyone focusing on mining rewards.

According to satoshi, and I agree, the long term security and stability of bitcoin is in the hands of bitcoin owners. Meaning people who own/hoard bitcoins have intrinsic interest in the security and stability of the system. These people will always have an incentive to run honest nodes. Self-interest causes them to support the currency and make sure the system is free from fraud.

I used to chat on this forum with a guy with the handle "knightmb". He owned 371,000 BTC. At current prices, knightmb's market capitalization is over $1.5 million dollars. He has a serious vested interest in the stability of bitcoin. From what I read, he no longer mines. I'm absolutely sure that he keeps an honest node running continually though. It is necessary, and trivial, for him to monitor the overall behavior the network. He can see at a glance that everything is in perfect compliance. If he notices non-compliant transactions creeping into the log, he will be the first to phone the developers and post a notice of an attack in this forum. If he has spent a single kilowatt of electricity on this monitoring in the past year, I will be shocked.

There is a transaction fee in bitcoin. But, it was never designed as a reward system. It was a preemptive defense against someone swamping the system with needless micro-transactions. (See the code comments.)

The pondering that "transaction fees might provide some future incentive" came via a consequence of the previous decision. According to satoshi, self-interest was always the long-term logic for supporting bitcoin. After all he named it a peer-to-peer currency. As such there is no higher interest than the self-interest of the peers.
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 07:40:13 PM
 #114

I just don't understand your concepts well enough to say, "let me propose an encoin like system, except..." Had I done that, I would have obviously been talking out my ass. I have no idea why you made most of your design decisions. Like say, why you changed 10 minutes consensus periods to X hours. How each miner is benchmarked against kWh. Or how effort based new coin allocation attempts to affect monetary policy.

All right, I'm going to at least try to convey my logic on how these systems converge into a stable price point in one post.

Quote
•   Network Trust Block difficulty will be based around an average network being able to find one block every six hours. 6 hours x 50 people x 200Wh = 60kWh or 6 ENC.

200Wh is the BIG MAGIC NUMBER of encoin. The 6 hours and 50 people are variables. If the average network had 100 people, the average network would have to find one block every 3 hours to equal 6 ENC. If the avg network was 25 people, it would be 12 hours. The hash algorithm difficulty would be based on this in the same way as bitcoin's except for like so:

200Wh * NumTotalUsers = total kWh ASSUMED to be used by the network and thus the goal for the average amount of coins awarded.
Hash/s / NumTotalUsers = AvgUserHashRate
AvgUserHashRate == 200Wh

In reality it is more complicated than this since not every user will stick around for the whole block and so on. I guess "AvgNumTotalUsers" might be a better variable name.

Now, if everybody is using exactly 200Wh and has the exact same hashrate and has the exact same cost for electricity, we are living in a perfect world. Obviously all kinds of things will affect this, and the user will have to determine in their own case whether or not it is profitable to mint coins.

BUT--because I mentioned there are voteable payout structures within each TrustNet that can help smooth out variations in efficiency. For example, set payout structures based on finish for best hash. 1st place hash always gets X%, 2nd place always gets X%, and so on (this is not how it works in pools and it simply can't be done this way). This will keep the race for the newest and best hardware down to a minimum, and people with inefficient hardware can siphon off a bit on the people with more efficient hardware (I'm talking in terms of Mhash/W or Mhash/J, please don't misinterpret this). But there will be a minimum to qualify, and a requirement to be present until the end of the block, and so on to keep abuse down. These are voteable properties (trust modules--another terrible name I know) so they can be adjusted down the road in the face of new exploits or whatever. Kinks will have to be worked out.

The point is to award electricity, not efficiency as I stated before. Encoin will require less of a hardware investment because of this which means it can potentially draw more people in. More people == more popular == currency is valued. And hardware investment uses a god awful large chunk of any ROI you might see for a very long time. So the less hardware investment the better. We're looking for sunk costs here.

Now with the whole TrustNet system, it is almost like a game. Gain levels (trust), get more coins, be able to join respected networks, and so on. Who knows, I may come up with a shitload more ideas (aliases for trustnets and users is one, cheaper global messages could be another, all kinds of things to help make it a community). If the network doesn't like them, they don't vote for that module. If eventually people do and the vote is >50%, then it becomes part of the network. It's so much more flexible, although it may be hard to see at this point. Nothing that trustnets can vote on will be able to change the value of the currency though. Clients will not accept that unless there is some other designer who comes along and decides to fork it. The potential for that can't be denied, it is the nature of open source.

But *anyone* can always become trusted and get the benefits. They just have to stick around awhile. And for every person you can convince to stick around, the more secure the network is. This does not mean the more hash power there is because of the cool-down and the ENC benefit. That stuff has to be worked on in a little more but let me give a quick example:

Say the ROI on a typical minted coin is 33%. An average coin costs 10kWh, say the average price is 0.15/kWh, so $1.50+33% = $2.00 sell price. Market "crashes" to $1.60. TrustNets go into cool down mode and only mint 1/10th the coins at 1/10th the electricity for 1/8th of the award--I'm thinking of allowing 1/2, 1/10, and 1/20 but we'll see. Now 0.75 ENC is made for the cost of 0.6 ENC and people who need to make money to see any use to minting get a 25% ROI inherent, but on a very small amount. If the economy is routinely stable, people can run Encoin as essentially a background process that uses very little of their GPU. The computer can still be (almost) fully used. Yet the network remains just as secure as before. It avoids proof-of-work being the end-all be-all form of consensus.

And all kinds of neat things can be done when you can rely on consensus in lieu of proof-of-work. When you can know how many people are out there and what the network looks like. When you can vote on little details of how the network operates. When you can chat with your fellow TrustNet members. When you don't have to worry about the network becoming vulnerable if the hash rate drops. LOL when you don't need a 8gb/s connection to use it, or download a 1GB block chain before you can even see your first transaction. I have a vision, and that vision is Encoin (but possibly by a different name hahah). Smiley

Quote
You gave constants for coin creation that seem unrelated to the transaction fees. I don't understand why you chose those constants and why (as both are part of monetary policy decisions) they are unrelated. If they are place holders to be calculated later that's OK. I just genuinely don't understand yet.

Coin generation has to be based on kWh, it can't change because then 1 ENC != 10kWh. So the only way to constrict the economy when in need is by transaction fees and allowing coin generation to securely reduce in output. They can not be tied together. Transaction fees could be variable, and perhaps there could be two fees, one for stable/expanding economy, and one for contracting economy. But this would have to be voted on by the TrustNets, the software can't decide on its own, it is against how I think this should work. That could piss off people who don't make coins. So I would really like to have a transaction fee set in stone.

Quote
What I'm trying to understand is to what value/function does this system converge: If a new ASIC is 100 times more efficient? If a big new vendor joins the network? If the price of electricity spikes? If in any situation, the value of coins tends either to zero or infinity, I know the algorithm is not stable.

If some new thing that only 1 or a few people had was way more efficient, then they would siphon some money off of the new coins being made. It's hard to calculate how much, but the bigger the network, the less it will take from each coin (and I have even more ideas to lessen the impact of this type of thing, but it is for a much more advanced version of the proposal). I don't know what you mean by a new big vendor joining. I don't see how the price of electricity could "spike" especially across the entire world at once. It should be a gradual process that will gradually increase the value of encoins vs fiat. The value of coins tends to 10kWh, whatever 10kWh is.

Quote
To combat increases in hardware efficiency over time, you propose rotating algorithms. Rotating doesn't seem to work, because if someone is willing to build an ASIC they might as well keep it around for when rotation comes back. 4 algorithms, 4 ASICs. Run when appropriate.

No, I proposed changing algorithms. I did think of this exact same scenario, believe it or not.

Quote
Beyond that, your concept seems to require competing engineers. Who decides if existing hardware is too efficient? Who gets to choose the next proof-of-work algorithm? How do you make everyone else adopt those new rules? That seems like a different kind of consensus building completely unrelated to your TrustNets.

If by "too efficient" you mean in the future where everything uses less electricity, I have an idea that will add in some deflation to the economy slowly, over a very long period. And it is simple and regulated and would not cause any drastic consequences like satoshi's boneheaded award halve. This is what I was referring to when I said I didn't want to give something away yet. This deflation can still be counteracted by increased minting and so on if necessary. The proof of work algorithm will be changed randomly, every X primary blocks, by using a hash of the previous block. When the developers (or anyone with clout) releases a new module with a new, futuristic hash algorithm, it will be added to the pool of algorithms already in use by a TrustNets vote. The vote is not a one time thing. When people upgrade their client, they will have an option to vote yes or no to this new potential change to the network. Then the client will automatically cast their vote during every primary block cool-down phase. Once >50% agrees, then it is added as a valid module.

Quote
I'm genuinely interested in understanding how your system meets its monetary policy goals. To me, all the other bits are optimizations to previously solved problems. They are interesting in their own right. I'm just interested in monetary policy first.

Let the people control whether or not coins are minted. Coins are always minted for approximately the same cost, so it is not like they are voting them into existence from nowhere like fiat. They always have an inherent value of 10kWh. Transaction fees are a mild deflationary measure to counter over-minting and low demand without requiring an expansion of the economy, even though stable economies tend to always expand as population increases.


I'm going to give some reasons why I chose 200Wh over 100 or 300.

100Wh disadvantage:
* Electric value enters the economy at a slower pace. People would have to adjust their GPUs to make sure they are using only approximately 100Wh, half or whatever it comes out to be. (I plan on having a helpful calculator in the program.)
* With a higher difficulty (time * computation, I'm referring to time here) of adding value to the economy, extreme deflation is a lot more likely if the network booms.
* Psychological. A month of effort nets you 7.2 coins if I keep the 10kWh figure. I could make it 5kWh I suppose.
* Potential for abuse. Hacked clients *will* come out that divert half of your GPUs resources to one node and half to another so that you can make double the profit. This isn't a huge problem, but by restricting it to 100Wh you are allowing easy access for some people to have this advantage over others. I suppose, in the end it really doesn't matter but it would waste network resources just to allow people who want to go full blast to go full blast.

100Wh advantage:
* FPGAs and what have you have less of an impact. While they're still going to be more efficient, they are not siphoning off as much of the economic value.
* Future cpu/gpu electricity usage going down could have less of an impact because instead of going at half the normal rate they could go full blast or whatever ends up being the equivalent.
* Since deflation is more likely in a boom, it would encourage more people to be part of a TrustNet (blah blah whatever you want to call them).
* There would be less "extra coins" in inflationary periods. e.g. the inflation won't be as big because people are not putting in as many coins before they figure out it's happening. So it could bounce back quicker.

300Wh disadvantage:
* A lot of people may not be using 300 watts worth, so they are getting a bonus even though they are not using as much electricity (assuming an efficient card).
* FPGAs could have a much larger impact if they become any significant portion of the economy.
* lot of extra coins in inflationary periods, may take a very long time to settle back to equilibrium.
* lot of extra coins in deflationary periods, that won't last long and the demand will probably all be grabbed up by anyone that was there before the boom.

300Wh advantage:
* basically the opposite of everything in the 100Wh disadvantage category.

Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 07:44:02 PM
Last edit: September 27, 2011, 08:30:32 PM by Etlase2
 #115

According to satoshi, and I agree, the long term security and stability of bitcoin is in the hands of bitcoin owners. Meaning people who own/hoard bitcoins have intrinsic interest in the security and stability of the system. These people will always have an incentive to run honest nodes. Self-interest causes them to support the currency and make sure the system is free from fraud.

I used to chat on this forum with a guy with the handle "knightmb". He owned 371,000 BTC. At current prices, knightmb's market capitalization is over $1.5 million dollars. He has a serious vested interest in the stability of bitcoin. From what I read, he no longer mines. I'm absolutely sure that he keeps an honest node running continually though. It is necessary, and trivial, for him to monitor the overall behavior the network. He can see at a glance that everything is in perfect compliance. If he notices non-compliant transactions creeping into the log, he will be the first to phone the developers and post a notice of an attack in this forum. If he has spent a single kilowatt of electricity on this monitoring in the past year, I will be shocked.

It's great if he comes here and makes a forum post. That doesn't mean it fixes anything. Bitcoin is still limp-dicked by an attack and going nowhere fast. Please read what I said again about what a continued attack against the network could accomplish. And AFAIK, unless he is looking and checking every single transaction that goes through the system, there is no automated checking for double spends or the like.

Quote
There is a transaction fee in bitcoin. But, it was never designed as a reward system. It was a preemptive defense against someone swamping the system with needless micro-transactions. (See the code comments.)

The ultimate end design is to keep people mining when there is no longer any significant award from the block payout. And stop implying my transaction fee is a reward. NO ONE GETS THE TRANSACTION FEE, IT IS DESTROYED. IT CREATES NEW DEMAND FOR COINS. IT IS CONTROLLED DEFLATION. EVERYONE WITH ANY BALANCE WHATSOEVER BENEFITS.

JohnDoe
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile
September 27, 2011, 09:07:11 PM
 #116

Well, it might not be. But just in case it is, I'm going to write down my logic. Maybe we can all bash on it and see where the logic takes us.

...

I think those rules tend toward some wandering equilibrium measured against the cost of electricity. I'm not totally sure of the exact function.

What does anyone else think?

I may be wrong, but I believe this sytem is flawed in the same way Encoin is. It assumes an equation will remain constant over time but it is more likely that it will vary. I'm referring to the assumption that an increase of X in difficulty will equate to an increase of Y dollars in the cost of mining. In the future that equation may change to X*1000 difficulty = $Y in cost, so because difficulty can only adjust linearly then at some point it will start playing catch-up with technological progress and so hyperinflation will ensue because it will always be profitable to mine.
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 09:31:46 PM
 #117

I may be wrong, but I believe this sytem is flawed in the same way Encoin is. It assumes an equation will remain constant over time but it is more likely that it will vary. I'm referring to the assumption that an increase of X in difficulty will equate to an increase of Y dollars in the cost of mining. In the future that equation may change to X*1000 difficulty = $Y in cost, so because difficulty can only adjust linearly then at some point it will start playing catch-up with technological progress and so hyperinflation will ensue because it will always be profitable to mine.

Now if only you understood that an increase in X difficulty is an increase in Y cost is precisely not how encoin works, maybe you would feel differently. It is based around market factors and incentivizing the creation of coins when it is profitable, and accounting for it when it is not in a way that still keeps the network secure.

Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 09:35:20 PM
 #118

I hate to respond to this post first, but it is quicker.

Your other post is much more enlightening. Thank you for that. I will respond in detail to that in a few minutes.

And AFAIK, unless he is looking and checking every single transaction that goes through the system, there is no automated checking for double spends or the like.
My point was, he can run a complete peer an look at and check every single transaction for a trivial cost. No mining is requires. This will give an overall sense of how many people trying to cheat. Even if he doesn't want to do that, he can download the block chain every few days and check it for consistency. This is a built in feature of every client that runs automatically when you start a peer. If there exists even a single double spend in the block chain, the system is fucked and it is time to call the programmers and alert the media. The data structure and transaction validation rules simply won't allow it to happen. If its there, it is impossible not to notice. (I can go into details about in-point, transactions, out-points and the directed acyclic graph structure if you like.)

And important point is knightmb doesn't have to worry about anyone stealing his existing coins. Even if everyone else stops mining, and someone has 100% of the CPU power, they still can't generate compliant transactions to take them. They also cannot fork the block chain and erase them. His transactions are long behind bitcoin's programmed in (mandated consensus) block locks.

Quote
The ultimate end design is to keep people mining when there is no longer any significant award from the block payout.
I understand what you are saying. I also agree that there is increased opportunity to cause mayhem if a huge majority of miner leave bitcoin all at once. But in the end it will be the vested interest of the bitcoin holders who motivate a solution. Even if it means changing long standing mining conventions.

Quote
The ultimate end design is to keep people mining when there is no longer any significant award from the block And stop calling my transaction fee a fucking reward. NO ONE GETS THE TRANSACTION FEE, IT IS DESTROYED. IT CREATES NEW DEMAND FOR COINS. IT IS CONTROLLED DEFLATION. EVERYONE WITH ANY BALANCE WHATSOEVER BENEFITS.
I completely understand your destroyed transaction fee and its purpose. I put a similar Tax in my post on the subject.

I wasn't talking about or implying encoin in the above statement. It was common banter on this site that *bitcoin's*  trivially small (at that time) transaction fee would provide the ultimate reward to incentivize bitcoin mining after the 21M coins had been distributed. The thinking was, as each coin's external value skyrocketed, the transaction fee's external value would increase with it.
Etlase2 (OP)
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
September 27, 2011, 10:28:37 PM
 #119

Your other post is much more enlightening. Thank you for that. I will respond in detail to that in a few minutes.

Cheesy

Quote
And important point is knightmb doesn't have to worry about anyone stealing his existing coins. Even if everyone else stops mining, and someone has 100% of the CPU power, they still can't generate compliant transactions to take them. They also cannot fork the block chain and erase them. His transactions are long behind bitcoin's programmed in (mandated consensus) block locks.

You say that as if this is possible in encoin. It is not. I was detailing a potential attack and how it was effectively worthless (actually, 6 million south of worthless). People misunderstand the scope of how the sybil attack is being defended against in my proposal. I was trying to clarify.

And no, he doesn't have to worry about anyone stealing his coins, he has to worry about the network becoming unstable and his coins being completely worthless (and we have to worry about him making our coins worthless in a sell-off). This is what I believe will eventually happen in a sustained 51% attack. Once the resources are gathered for that 51% attack, it will be easier and easier to continue it or start it again as miners are discouraged that they are not mining nearly as many coins and users are discouraged that transactions are not being confirmed or transactions that have been confirmed are being unconfirmed. Cascade of effects. I have seen people say, "well lol their coins will be so valuable they'd be stupid to take the network down."--referring to the attacker. This is the kind of logic that goes into thinking the only attempt would be a double spend. *all* factors must be considered, and I believe an attempt to take the network down has been grossly under-discussed.

Quote
I completely understand your destroyed transaction fee and its purpose. I put a similar Tax in my post on the subject.

Then why did you put refunds in? Refunds are senseless to what the fees are trying to do. You made the system more complicated and convoluted with different difficulties et al.

Without the tax, and if you concede that mining needs a reward since it secures the network (or from a different perspective, securing the network needs a reward and it needs a secure way to pay that award which is achieved by mining), a perfectly stable economy is impossible as it will continually inflate.

Red
Full Member
***
Offline Offline

Activity: 210
Merit: 111


View Profile
September 27, 2011, 10:47:02 PM
 #120

Quote
•   Network Trust Block difficulty will be based around an average network being able to find one block every six hours. 6 hours x 50 people x 200Wh = 60kWh or 6 ENC.
...

Now, if everybody is using exactly 200Wh and has the exact same hashrate and has the exact same cost for electricity, we are living in a perfect world. Obviously all kinds of things will affect this, and the user will have to determine in their own case whether or not it is profitable to mint coins.
OK, I'm with you so far. The perfect world generalization is fine with me, to get on with discussing the more interesting bits.

The only kibitz I offer is that I think you mean "200W" rather than "200Wh". If someone's power supply is drawing 200W and they run their computer for 6 hours. The electric company bills them for 1.2 kWh.



BUT--because I mentioned there are voteable payout structures within each TrustNet that can help smooth out variations in efficiency.
...
Nothing that trustnets can vote on will be able to change the value of the currency though.
I understand all of this and have no criticisms. The intension is to encourage people to participate in these partnerships. Motivations might change, so you allow flexibility to adjust. Nice.

Clients will not accept that unless there is some other designer who comes along and decides to fork it. The potential for that can't be denied, it is the nature of open source.
Agreed. Not interesting in forking. It creates something that is not the system we are discussing.

Say the ROI on a typical minted coin is 33%. An average coin costs 10kWh, say the average price is 0.15/kWh, so $1.50+33% = $2.00 sell price. Market "crashes" to $1.60. TrustNets go into cool down mode and only mint 1/10th the coins at 1/10th the electricity for 1/8th of the award--I'm thinking of allowing 1/2, 1/10, and 1/20 but we'll see. Now 0.75 ENC is made for the cost of 0.6 ENC and people who need to make money to see any use to minting get a 25% ROI inherent, but on a very small amount. If the economy is routinely stable, people can run Encoin as essentially a background process that uses very little of their GPU. The computer can still be (almost) fully used. Yet the network remains just as secure as before. It avoids proof-of-work being the end-all be-all form of consensus.
OK, I fundamentally understand "cool down" mode differently now. I thought it was a property of the system as a whole. After the X hour period generating a PB, *every* TrustNet goes into cool down *phase*. I appear to have been mistaken. Each network makes a decision on how much electricity it wants to risk mining at each mining interval. That makes much more sense to me now.

I have some questions about the non-linearity of the cool down mode rewards. But I want to think about things more in light of this insight.

And all kinds of neat things can be done when you can rely on consensus in lieu of proof-of-work. When you can know how many people are out there and what the network looks like. When you can vote on little details of how the network operates. When you can chat with your fellow TrustNet members. When you don't have to worry about the network becoming vulnerable if the hash rate drops. LOL when you don't need a 8gb/s connection to use it, or download a 1GB block chain before you can even see your first transaction. I have a vision, and that vision is Encoin (but possibly by a different name hahah). Smiley
I agree completely. But I want to point out that a lot of the benefits you are referring to come from trust in the humans behind the TrustNet abstractions. You can't chat with the code and ask it to vote on its best interest. I still think "Trust" means humans trusting humans. Compliance means nodes can't cheat.

Most of the comments I have made should be viewed from the perspective that I totally agree with you here. I also want to take advantage of the unique advantages that come from knowing your fellow human peers.

---

I'm going to comment on the rest after I've given things a little more thought.

Thanks for the new insights!
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  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!