Bitcoin Forum
December 04, 2016, 04:01:50 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
Author Topic: [ANNOUNCE] EnCoin - An alternative with a completely different paradigm  (Read 10594 times)
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 01:38:55 AM
 #81

Now I wasn't criticizing the difference between expansion and contraction technologies. However, when I see differences in the dynamics I like to pause and think is that a requirement or a consequence?

Well, if you want, you could propose that certain networks work to remove coins from circulation. I'm not sure how it would be accomplished, but I guess it could take a percentage of coins from every wallet. Then the dynamics could be quite similar.

Quote
In the expansion case I understood that additional miners could come in when it was profitable to create new coins. That makes expansion non-linear. Contraction on the other hand, while not linear, is less flexible.

Yes, but you are trying to unmake that which has already been made. No matter what, it is still an improvement over inflationary fiat.

Quote
As an extreme example, suppose Silk Road decided to move from bitcoin to encoin. The economy suddenly increased 10 fold. I'm sure miners would come in to create coins as profitably fast as they could. Now suppose Silk Road got busted by the FBI and the economy fell back to its previous state. I ponder whether the system could adjust with the given parameters. (I haven't reached any conclusions)

It would not perform well, in my estimation. But at least real market forces are at work to cause this, not an early adopter flooding the market with coins. At some point I will try to run some numbers to see how they come out. It will be imaginary, but at least it could provide a guideline around possibly setting the transaction fee.

Quote
I don't mean to propose that voting for fees is a good idea. I think aligning incentives is a much better way to let the market handle itself. A way to make the contraction rate more flexible, would be to tie it directly to the price of electricity as is used for expansion. (If inflation goes up, fees go up.) Or to the consistency of the contraction. (After X months of consistent contraction, fees go up to Y to speed things up) Those are just idle thoughts. Not well thought out proposals.

Tying it in to the price of electricity means the software needs to know the price of electricity. This can't be done in a reasonable or reliable way. The software has no way of knowing if the market is in an inflationary period, they are two very diverse entities. The consistency of the contraction, as you call it, would be one possibility that could be programmed. However, then you are relying on more magic numbers to control the economy rather than letting itself work it out. This is dangerous, and if you get it wrong, you're stuck with it (or a chain fork). And yet still, the network can stay just as secure as before (or at least a sizable percentage as secure), but using a lot less electricity. Bitcoin can't stay as secure in a contraction because miners won't keep putting effort into a completely unprofitable venture.

And all of this ignores the possibility of an expansion relatively soon after the contraction. If all of those coins are removed as quickly as possible to reach equilibrium, you deny people the opportunity of their value in expansion--especially to those who were actually spending and helping reach equilibrium. You also waste a lot of previously used electricity. Food for thought.

1480824110
Hero Member
*
Offline Offline

Posts: 1480824110

View Profile Personal Message (Offline)

Ignore
1480824110
Reply with quote  #2

1480824110
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
September 26, 2011, 04:38:23 AM
 #82

I see from your previous two posts that I have taken a mental tangent from some of your proposal details. I went back and re-read your proposal again. Doh, I hadn't snapped that you are using the word "trust" in multiple ways. Network Trust in the sense of "a body of trustees/a charitable trust". In later sections you talk of Trust in the "firm belief in the reliability, truth, ability, or strength of someone or something sense."

Anyway, my bad.

On the other hand, you say "EnCoin eschews the entire need for pools by having network trusts... There is no competition between Networks for coins." Which seems to mean that you take the most wastefully inefficient process in bitcoin, then make it redundantly wasteful in its inefficiency.

Now keep in mind that I'm long on record in my opposition to using needless proof-of-work calculations to prevent tampering with the transaction DAG. It's a little clever and a lot ridiculous.

--- History ---

Bitcoin was invented to solve one particular philosophical problem. Say we have a set of anonymous individuals, none of whom trusts any of the others. To whom are we going to trust the common transaction history? The concept of a digital currency using a trusted record keeper was already well developed. The design decision was of course we'll all keep our own copy of everything and we'll all redundantly do all the work ourselves.

That came coupled with another problem. How do reconcile our individual transaction DAGs to guarantee they remain constant over time? The design decision was of course, every 10 minutes we'll *randomly* choose one person's new transactions and pass them around as a block to everyone. The others will throw away all their personal knowledge of new transactions and start again. Then, hopefully, the transaction participants will keep redundantly resubmitting the same transaction until someone notices.

But what if the network becomes partitioned and nobody notices? How do we reconcile forks of the block chain? The answer of course, is throw away one fork and those folks adopt the other fork and start again. Which fork? The longer? The one with the most transactions? The bigger network? What if someone claims they've been partitioned for six months and want us to throw away everything and user theirs? What if, what if, what if...

The design decision was of course the proof-of-work concept. The real question you should be asking yourself is, why would somebody design a distributed transaction processing system that might throw away a ridiculous number of previously verified transactions—WITHOUT telling anyone! I mean WTF? The developers acknowledged this by adding specific block locks into each new client release.

How do they decide which blocks to lock in as the one true fork? Human consensus! "Hey, anyone got a problem with me locking the chain to here? OK, done!" Poof! Millions of hash computations tossed into the trash bin with one line of code.

--- EnCoin ---

So what's my point?

EnCoin is deliberately making different design choices than bitcoin.

1) You have a set of non-anonymous peer networks who intend to "trust but verify" each other's work. They all intend to know and trust their network members as well.
2) You treat and reconcile transactions individually, rather than as opaque blocks. Hopefully you also detect and notify some humans on simultaneous double spend attempts.
3) Your network of known trusted peers can't be forked without someone noticing.
4) Your system can never throw away blocks of transactions willy nilly.

As far as I can tell, you have *zero* need for a complicated proof-of-work to keep your "primary block" transaction accounting safe.

The only reason to start proof-of-work *mining* calculations is in hopes of arbitraging some newly created coins. If there is no hope of arbitraging these coins, there is no point in *mining* coins that are worth less then the cost to mine them. That is the key dynamic in your system that I see keeping the monetary policy stable.

So who, does all the Primary Block accounting if the miners don't?

EVERYONE who owns coins! Are you going to accept a hundred dollar bill from a stranger without looking for the hologram and security strip? That's what the transaction DAG/"primary block list" is for.

In your case you might delegate the dynamic transaction validation to at least one trusted individual in each trust network. But that is just an optimization to allow trusting lazy clients. As a general rule, receiving, validating and storing incoming transactions is trivial compared to the current proof-of-work calculations. You could run the transaction account part of your trust network peer on a cell phone using batteries.

---

Anyway, end of rant.

I'll address the rest of your responses in another post, but I needed to say that for context.

I'm interested to know if you think you still need to throw kWh of electricity at your Trust Network just to keep up with transaction accounting. I see zero reason for that.

I do understand why you might want to throw discretionary kWh at the monetary expansion problem.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 07:46:36 AM
 #83

I see from your previous two posts that I have taken a mental tangent from some of your proposal details. I went back and re-read your proposal again. Doh, I hadn't snapped that you are using the word "trust" in multiple ways. Network Trust in the sense of "a body of trustees/a charitable trust". In later sections you talk of Trust in the "firm belief in the reliability, truth, ability, or strength of someone or something sense."

Yeah, the terminology of the proposal is terrible at this juncture--I repeatedly swap between using "networks" or "trusts" to refer to Network Trusts too. That is #1 priority to fix in the next version of the proposal. Got any ideas on what to call Network Trusts? So far I have come up with "TrustNets". Smiley FWIW, I hadn't noticed you confuse the terminology anywhere...

Quote
The design decision was of course the proof-of-work concept. The real question you should be asking yourself is, why would somebody design a distributed transaction processing system that might throw away a ridiculous number of previously verified transactions—WITHOUT telling anyone! I mean WTF? The developers acknowledged this by adding specific block locks into each new client release.

How do they decide which blocks to lock in as the one true fork? Human consensus! "Hey, anyone got a problem with me locking the chain to here? OK, done!" Poof! Millions of hash computations tossed into the trash bin with one line of code.

Right, instead of the developers deciding this, every new primary block is decided this way. That why it isn't necessary for a new user to have any block but the most recent. Well, that and the fact that coins don't need to be traced back to their origin to prove they exist. I'm pretty sure there will be some kind of service (for a fee, of course) available to allow users to verify older transactions or get copies of older blocks, etc. But for how long someone retains a number of primary blocks is up to them. I'm thinking 30 days will be a minimum for the software to enforce, as the block chain will get very large very quickly with every account balance being stored in each block. And most likely those 30 days will be free to be queried by users so that they can check to see what transactions were made to them and so on while they were offline.

This again reduces anonymity though because when a user wants to know "what happened to wallet X" the network node that they're talking to has a reasonable idea that this IP belongs to that wallet. But I have ideas to obfuscate that a little bit (they aren't that good though, I will need help in designing this aspect).

Quote
So who, does all the Primary Block accounting if the miners don't?

EVERYONE who owns coins! Are you going to accept a hundred dollar bill from a stranger without looking for the hologram and security strip? That's what the transaction DAG/"primary block list" is for.

Everyone who owns coins are not exactly doing the accounting. This is where the points-based trust level of the Network Trusts comes in to play.

Say there are network trusts A-D, with trust points like so:
A - 25
B - 100
C - 4
D - 75

The total trust of the network being 204.

User Q wants to send 50 coins to user I, so he contacts a node he knows to be on Network Trust A and sends the transaction. "A" gets the transaction, includes it with every other transaction they've received in the last 15 seconds or so, then signs it and sends it along to every other Network Trust that they are connected to (which, in a perfect world, should be nearly all of them). 15 seconds later, user I gets confirmation that networks A and B have signed it. Knowing that the total trust is 204 and A+B = 125, more than half of the network trust has agreed that this transaction is valid, and now it can not be overturned. If user I sees that only A+D have signed, that is only 100 trust, not more than half, and the transaction is currently not reliable. If A+D+C sign it, then again we are over half, the transaction can be trusted.

Quote
In your case you might delegate the dynamic transaction validation to at least one trusted individual in each trust network.

Actually, the way I see it is that members of a Network Trust stay in contact with 4 or 5 if their network peers regularly, and those stay in contact with 4-5 other network peers, and so on. Each peer knows the address of every peer in their network in case Something Really Bad™ is happening (all 4 or 5 peers are disconnected, or all 4 or 5 appear to be doing shady stuff, or something similar). But during this process they will be putting a block of recent transactions together (a block so EVERY transaction doesn't have to be signed independently by EVERY network trust--this is a big waste of resources as verifying signatures is much more CPU intensive than verifying hashes) and the network trust will agree as a whole on what block of transactions to sign and send out. The validation part should be trivial as all that needs to be done is take Current Account Balance, minus Current Transaction Amount, plus/minus Existing Transactions that are not in the primary block yet and make sure this number is Greater Than Zero. Smiley

Quote
You could run the transaction account part of your trust network peer on a cell phone using batteries.

Not exactly since the peers will also be working to mint coins. But since the primary block is so much smaller than the comparable bitcoin blockchain, a cell phone app only needs the most recent block and CAN verify, independently, whether or not a transaction is valid. Requiring only a few megabytes rather than potentially gigs and gigs that bitcoin will eventually require.

Quote
I'm interested to know if you think you still need to throw kWh of electricity at your Trust Network just to keep up with transaction accounting. I see zero reason for that.

This is why I came up with the idea of the cool-down mode for network trusts. If the network is in contraction, or if some people don't feel like using 100% of their GPU for mining all the time, they can instead use 10% (figure up for debate, this may only be 5%), but still secure the network as if they were using 100% since it goes by trust instead of computational power. It isn't necessary to throw kWh at the network for accounting, but security. Security must be paramount. That is why I think giving a bonus for being in the cool-down mode is a good idea. You want as many people as possible to secure the network. And with good security comes accurate accounting.

Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 03:42:11 PM
 #84

Since this came up in an IRC discussion, I want to see if anyone would care to poke holes.

http://en.wikipedia.org/wiki/Sybil_attack

"A Sybil attack is one in which an attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous entities, using them to gain a disproportionately large influence. A reputation system's vulnerability to a Sybil attack depends on how cheaply identities can be generated, the degree to which the reputation system accepts inputs from entities that do not have a chain of trust linking them to a trusted entity, and whether the reputation system treats all entities identically."

A trusted identity does not come cheap in the EnCoin proposal. With a maximum TrustNet (temporary new name for network trusts) trust of 360, it would take 1 year to become among the most trusted. This would require finding at least one block a day. Someone else can calculate the variance, but to avoid losing 10 trust by missing a block, they would probably have to shoot for at least 3 blocks a day. At 4 blocks a day with average equipment, they would have to spend over $10k in electricity (not including hardware). So if we say 3 blocks, it would be closer to $7500, but let's just call it $10k for hardware costs.

In thinking about this actually before the IRC conversation, I realized it is more secure to force user id trust to be at minimum the same as network trust. So trying to infiltrate more trusted networks won't achieve anything. Also, on top of signing with the network ID, each user will have to sign their communications. This helps for scenario 2 below.

Anyways, if there are 100 networks (5,000 people, hardly out of line considering bitcoin has around 60k mining), they would need around 60 or more networks to keep up with the network if it is growing even slightly. Thus approximately $600,000 to perform a >50% trust attack. Now, for the scenarios I posited.

ATTACK: TrustNet tries to pay itself too much money
STATUS: Impossible. The total network decides on what the primary block is. TrustNets only put an award payout into their TNB (TrustNet Block) based on percentage. If >50% of the total network trust agrees to pay itself more, the clients will not agree with their primary block. In the honest network, all of those trusts will be set to 0. All of the user trusts will (most likely) be set to 0, and funds discarded. If an individual network attempts this, by whatever flawed reasoning, honest users will broadcast a message showing who agreed to the new block so that their network does not lose trust, and all the dishonest users lose all trust and funds.

ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)
STATUS: Possible, but won't accomplish much. A “bad spend” happens when a spend is approved for more than what exists in a specific wallet. Every TrustNet does not necessarily know how much exists in a given account because they may not have received every transaction yet. If a TrustNet receives what it considers a bad spend, it will ask for all transactions to date (since the last primary block) for this wallet. Since TrustNets should be connected to more than one person from each other TrustNet (if not, they can still check with other TrustNets), they can multiply verify that they have missed a transaction, or that the node that originally sent the bad spend is being subversive. If the node is being subversive, a broadcast will be announced showing proof. They will have their trust set to 0 and funds removed.

ATTACK: Control 50% or more of the total network trust and use it to change wallet balances
STATUS: Possible, and may cause temporary, but correctable problems. If an agency takes control of 50% or more of the trust, they may decide to put whatever amount of coins in any wallet they choose. Assuming the client is brand new and has no previous blocks, they could get away with any amount. If the client has a recent block, warning flags will be raised for any suspicious amount of coins added to a wallet (e.g. more coins than the network could have created in the mean time). Since some clients will have the most recent block prior to the takeover, the attacker must account for this and make sure the amount is within reason. Note that the amount of effort required to pull off this attack would create far, far more coins than the attack itself. The attacker could also move balances from one account to another which would be less easily detected. Since this could only be proven by a complete transaction log (the size of which would be very high if the network averaged many transactions per second), being able to detect this easily might not be feasible in the future. Early on with few transactions, it will be easy to spot. This attack only works if the user is connected to only dishonest nodes. Honest nodes will be able to immediately point out that the dishonest network cannot prove that those balance transfers took place. Far in the future, this attack would cost months of time and could cost millions in electricity for a temporary disruption of service for some users. After that, the process would have to start completely anew as those TrustNets and users would lose all trust.


Can anyone give me actual scenarios of attack on the network that I can try to refute? Because the (2 person) consensus in IRC was "lol it's not even web of trust, just time"

$6m if there are 50,000 people on the network


edit: hell, I just realized that this attack could be thwarted even more easily by requiring all TrustNets to sign a hash of the new primary block with a hash tree of the signatures of the individuals that make up that that TrustNet. What like a few hundred bytes per TrustNet, a few hundred kb to verify that thousands of people agreed to this primary block, or that there has been a split...

JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
September 26, 2011, 06:07:55 PM
 #85

So... I did come up with something. But since it is not an immediate threat and does not currently matter, I feel like holding it back at this time.

Are you serious? This is the main point of your currency. If it can't adjust itself to match technological progress then Encoin is worthless. Do you really have a plan or are you just pretending to have a plan?
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 06:21:21 PM
 #86

Are you serious? This is the main point of your currency. If it can't adjust itself to match technological progress then Encoin is worthless. Do you really have a plan or are you just pretending to have a plan?

lol I come up with an idea to mitigate a scenario that may not ever happen, that had I not even mentioned probably wouldn't have even been brought up, and suddenly Encoin will be worthless if it doesn't adjust.

Not to mention FPGAs have already been covered by changing the algorithm, as those are the far more likely threat.

Not to mention if things really got out of hand, forking (in the sense that a major change must happen or the system is going to stop working effectively) is still always a possibility. One that I have a feeling bitcoin will make use of at some point soon.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
September 26, 2011, 06:39:53 PM
 #87

Part of my confusion is that you are not separating Physical entities from Logical entities.

As best I can tell, a "Network Trust" is a logical grouping of physical peers. I'm not sure if you consider these peers to be the humans or these human's (zero?, one or more) computer nodes. Can I be part of a "Network Trust" (to send and receive coins), without running a node at all? Do I have to be part of a "Network Trust" to send and receive coins? I guess I'm asking, are NT's optional just so I can share in your reward scheme?

Everyone who owns coins are not exactly doing the accounting. This is where the points-based trust level of the Network Trusts comes in to play....
I understand the logic of what you said. But who (what peers) is actually doing the work for a given "Network Trust" group? Does every NT member receive every broadcasted block from the other NTs? Or is there one-or-more delegates for each NT that NT members are *required* to trust? That was what I was referring to below.

Quote
In your case you might delegate the dynamic transaction validation to at least one trusted individual in each trust network.

Actually, the way I see it is that members of a Network Trust stay in contact with 4 or 5 if their network peers... But during this process they will be putting a block of recent transactions together...
I got really confused about your use of the term network peers here. Sometimes it seems to mean intra-NT peers. Other times it seems to mean inter-NT relationships.

And the statement "they will be putting" is completely nebulous. I understand why they will be putting together a block. I just have no idea who they are? Is there a single delegate for the NT? Do the members of the NT collaborate together? How do they share data? Who is responsible for resending the block every few seconds?

It seems like there is a delegation pattern at work here. But then you say "Each peer knows the address of every peer in their network in case Something Really Bad™ is happening (all 4 or 5 peers are disconnected, or all 4 or 5 appear to be doing shady stuff, or something similar)" which implies each peer is monitoring his NT peers, not trusting them.

I'm really confused.


Quote
You could run the transaction account(ing) part of your trust network peer on a cell phone using batteries.
Not exactly since the peers will also be working to mint coins...

a cell phone app only needs the most recent block and CAN verify, independently, whether or not a transaction is valid.
Again, when I said "account(ing) part of your trust network peer," I was thinking about the delegate pattern. Supposed you delegated *all* the 1) receiving of NT member's transactions, 2) validation of NT member's transactions, 3) transaction block broadcasting and receiving, 4) validation and recording of inter-NT transactions. This could easily be done using only the power of an iPhone.

If you are not delegating the above 4 things to some "trusted" delegate node, then I'm totally confused about the dynamics of your NT group of nodes. If each member does these things individually without trusting the other members, then the batching, signing, and sending seems redundant.

Quote
I'm interested to know if you think you still need to throw kWh of electricity at your Trust Network just to keep up with transaction accounting. I see zero reason for that.

This is why I came up with the idea of the cool-down mode for network trusts. If the network is in contraction, or if some people don't feel like using 100% of their GPU for mining all the time, they can instead use 10% (figure up for debate, this may only be 5%), but still secure the network as if they were using 100% since it goes by trust instead of computational power. It isn't necessary to throw kWh at the network for accounting, but security. Security must be paramount. That is why I think giving a bonus for being in the cool-down mode is a good idea. You want as many people as possible to secure the network. And with good security comes accurate accounting.

I don't mean to be dense, but I'm totally baffled by this last paragraph.

We got all the way here, talking about a distributed system for trusted and verified transaction accounting. Never once did you mention any necessity for *mining* in order to guarantee transaction validity. Validity was guaranteed through transaction block signing (consensus notarization).

What on earth does mining secure? The only thing I see that it can possibly protect is the reward system for mining. This system seems to operate completely independently. In actually, it doesn't seem to secure the transaction system. It seems to rely on the consensus relationships of the underlying transaction system to frustrate subverting the mining reward system.

Again, I'm baffled.

I thought the mining system was a way to optimize monetary policy. Where "optimize" means, expand or contract the money supply as appropriate to maintain coin value stability. That is a hard problem and worth my time to think about.

On the other hand, levying a tax on every transaction and using *mining* as justification for redistributing this tax among miners... Well that seems to be an unnecessary problem to solve at all. At best it's a marketing problem. That's not at all where I want to waste my mental energy.
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
September 26, 2011, 08:49:39 PM
 #88

lol I come up with an idea to mitigate a scenario that may not ever happen, that had I not even mentioned probably wouldn't have even been brought up, and suddenly Encoin will be worthless if it doesn't adjust.

May not ever happen? You seriously think calculating won't get more energy efficient? It will happen. And actually it has been brought up. I asked how you intend to equate encoins to kwh in my first post in this thread. All I've heard is about a magical algorithm that somehow takes information impossible to predict into account to maintain the equation 1 ENC = 10 kwh accurate.

Not to mention FPGAs have already been covered by changing the algorithm, as those are the far more likely threat.

What algorithm? I don't see it anywhere. It's only a hypothetical algorithm.

Not to mention if things really got out of hand, forking (in the sense that a major change must happen or the system is going to stop working effectively) is still always a possibility. One that I have a feeling bitcoin will make use of at some point soon.

You are going to fork every time technology screws your currency? I thought you had a super plan to prevent that. Or was that the super plan?
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
September 26, 2011, 08:55:12 PM
 #89

"A Sybil attack is one in which an attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous entities, using them to gain a disproportionately large influence.

This post does not inspire confidence at all.

You know of course that the Sybil attack was one of the prime motivations for developing the wacky proof-of-work calculation. The logic goes, if we are going to have a group of anonymous peers, and we need to vote on things...

The answer of course is, never let anonymous fictional entities vote. It's silly.

Fortunately for you, EnCoin has relationships between non-anonymous trusted parties that investigate scamming, broadcast notices to the public, ban the scammers, and report them to the appropriate authorities. If the authority in your trust network can't do this, why on earth would you "trust" them?

ATTACK: TrustNet tries to pay itself too much money
ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)
ATTACK: Control 50% or more of the total network trust and use it to change wallet balances

The fact that you consider these possible (but implausible) attacks on your proposed system shows that your basic consensus (100% agreement) mechanism is non-existent.

Validity means a transaction is 100% in compliance with the rules of the system. There is no negotiation involved. No vote is ever required.

ATTACK: TrustNet tries to pay itself too much money

This should be trivially detected and prevented by *every* other TrustNet. It is either a defect in that peer, or fraud committed by the peers owner. The defective/fraudulent TrustNet entity and all its users should be banned until trusted humans determine which problem it is.

ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)

WTF? How can any group of peers abuse the TrustNet's trust? The TrustNet was supposed to be the party everyone else was trusting? The only way to attempt a double spend is to simultaneously submit two conflicting transactions to different TrustNets. Both would be accepted and each would "race" the other to see which got "51% Trust" first.

That whole concept is STUPID and IRRESPONSIBLE.

Both transactions are part of a single common attempt at fraud. This should be detected in 100% of the cases, by 100% of compliant Trust Networks. In EnCoins case it should happen within 30 seconds or so. Both transactions should fail immediately so the targets of the fraud can be notified before irretrievable property changes hands.

All source accounts (transaction in-points) of both transactions should be locked system-wide. That prevents further attempts at fraud. Notice of the fraud attempt should be broadcast globally so nobody attempts to deal with the fraudster again. 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.

ATTACK: Control 50% or more of the total network trust and use it to change wallet balances
STATUS: Possible, and may cause temporary, but correctable problems.

REALLY! You even consider this a possibility? Arrg! If this can't be immediately detected by 100% of compliant Trust Networks and broadcast system-wide, then really there is no reason for anyone to trust your EnCoin at all.

I mean really, you are claiming that periodically your system "cools down" to reach a common consensus (100% agreement) point. At that point 100% of the Trust Networks agree on 100% of the account balances. You are saying that somehow 51% of the networks can conspire to change a balance or submit a fraudulent transaction and the other 49% either can't detect and/or can't prevent this fraud?Huh

Any single compliant network must be able to validate the compliance of every other network. If they can't there is zero point in anyone trusting even an honest "Trust Network".

---

Suddenly I have zero confidence in your proposed implementation.
Convince me that I'm wrong.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
September 26, 2011, 09:41:39 PM
 #90

I asked how you intend to equate encoins to kwh in my first post in this thread. All I've heard is about a magical algorithm that somehow takes information impossible to predict into account to maintain the equation 1 ENC = 10 kwh accurate.

I agree. That is really the question I showed up to hear the answer to also.

I hear philosophy about why a constant value is good. I agree with that philosophy. I don't yet see how anything in the proposal facilitates that though.

---

As a side note, I think I have actually come up with the beginnings of algorithm that might suffice. It is clearly only a partial solution. I haven't solved the bootstrap problem.

Technically, in my case, it's not 1 ENC = 10 kwh. It's closer to 1 ENC = 10 kwh * avg($/kwh). One ENC trades in dollars at the same price that 10 kwh trades in dollars. I don't know if 10 is the right constant either. It's a little more nebulous than that.

So hypothetically, say we had a currently running ENC system where the price of 1 ENC = $X = cost_of(Y kwh).
The goal of my algorithm is to cause the $_value_of(1 ENC) to tend toward the value_of(const Y kwh). This relationship should hold over time, even with changes in technology and changes in the price of electricity.

Again, I can't bootstrap this yet. Nor can I drive the ENC price toward any particular Y value. But if it is currently at a particular Y value, I think I can keep it there over time.

Anyone interested?
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
September 26, 2011, 10:28:53 PM
 #91

The goal of my algorithm is to cause the $_value_of(1 ENC) to tending to the value_of(const Y kwh). This relationship should hold over time, even with changes in technology and changes in the price of electricity.

How? I don't see how this is possible.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 10:43:31 PM
 #92

lol I come up with an idea to mitigate a scenario that may not ever happen, that had I not even mentioned probably wouldn't have even been brought up, and suddenly Encoin will be worthless if it doesn't adjust.

May not ever happen? You seriously think calculating won't get more energy efficient? It will happen. And actually it has been brought up. I asked how you intend to equate encoins to kwh in my first post in this thread. All I've heard is about a magical algorithm that somehow takes information impossible to predict into account to maintain the equation 1 ENC = 10 kwh accurate.

What I said at the end of that post was referring specifically to if the average power consumption of devices to run the software went down. I thought I was fairly specific about each case.

Quote
What algorithm? I don't see it anywhere. It's only a hypothetical algorithm.

I am referring to the hashing algorithm. FPGAs are designed to run one specific set of instructions. If the hashing algorithm changes, you need to build a new FPGA. Not that useful!

Quote
You are going to fork every time technology screws your currency? I thought you had a super plan to prevent that. Or was that the super plan?

Now you are being purposefully dense for the sake of argument. To expect that a currency based around a cost to produce that is based around computers using energy based around solving mathematical equations where that equation will always result in the same (value $$) amount of energy used until the end of time is ridiculous.

One huge, glaring flaw in bitcoin that is lacking the obvious foresight of this type is evident when the btc award halves. Since there is no comparable difficulty change, if the (sell) value of BTC is lower than what the new cost to produce will be, the difficulty is going to be far higher. If half the network leaves, difficulty is immediately doubled for the other half. Now difficulty is doubled AND award is halved. That means for the people that don't leave, they are now making 1/4th the amount of BTC for their energy and time output as the block before. Difficulty adjusts every 2 weeks on average, so it may not end up adjusting for over a month or more as people struggle to find very difficult blocks. This could cause a meltdown in the mining network.

JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
September 26, 2011, 11:19:06 PM
 #93

To expect that a currency based around a cost to produce that is based around computers using energy based around solving mathematical equations where that equation will always result in the same (value $$) amount of energy used until the end of time is ridiculous.

Well I'm glad we are in agreement. Thank you, I don't have any further business with Encoin.
Minsc
Full Member
***
Offline Offline

Activity: 210


View Profile
September 26, 2011, 11:45:32 PM
 #94

Part of my confusion is that you are not separating Physical entities from Logical entities.

Astral entities?

1DcXvfJdeJch9uptKopte5XQarTtj5ZjpL
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 11:45:48 PM
 #95

Part of my confusion is that you are not separating Physical entities from Logical entities.

As best I can tell, a "Network Trust" is a logical grouping of physical peers. I'm not sure if you consider these peers to be the humans or these human's (zero?, one or more) computer nodes. Can I be part of a "Network Trust" (to send and receive coins), without running a node at all? Do I have to be part of a "Network Trust" to send and receive coins? I guess I'm asking, are NT's optional just so I can share in your reward scheme?

Again, a problem of poor terminology in the proposal. There are two types of computers that use the network--computers providing the service of running the network, and computers that are making use of the services offered by the network. Whatever I end up calling these will probably not be peers or nodes or users or whatever as those terms are confusing. So let's just use client and server for now. Client Joe wants to spend money so he signs a transaction that sends 5 ENC to Client Bob. Joe connects to server Mary and sends the signed transaction. Mary is a part of a TrustNet/NT and checks to make sure Joe has enough money in his account, signs it with her user ID and TrustNet ID, then passes it along to every other TrustNet. Once Mary receives confirmation back from >50% of the total network trust, Mary lets Joe know that the transaction has been approved.

Now one issue here is that Bob isn't notified of the payment unless he specifically tells his server to keep an eye out for him. So Bob tells server Hillary that whenever an approved transaction comes through with his address, let him know about it.

Since this system relies on a direct ip address->wallet address correlation, I am thinking on a layer of obfuscation that is similar to bitcoin, but one that removes a lot of the burden off of the servers and keeps it on the clients. So there would be, in effect, "the city" where the TrustNets operate and exchange information, and "the cloud" where clients communicate with each other about all the stuff that the city is doing. If Joe wants to send a transaction pseudo-anonymously, he can tell his connected peers in the cloud to send his transaction a random number of hops (client A to B, B to C, C to D, and so on) before sending it to the city. If everybody does this, it is not possible for city or cloud peers to know where the transaction originated. But it makes things a bit complicated when the city sends confirmations out, as they may have to roll around the cloud for awhile without much guarantee that the person who cares about the transaction will see it. This concept is very work-in-progress at this point.

Basically, in a perfect world, every server would be connected to enough other servers to maintain network cohesiveness, and must also each be connected to the total number of network clients divided by the total number of network servers.

Quote
I understand the logic of what you said. But who (what peers) is actually doing the work for a given "Network Trust" group? Does every NT member receive every broadcasted block from the other NTs? Or is there one-or-more delegates for each NT that NT members are *required* to trust? That was what I was referring to below.

Each member of a TrustNet is working on the hashing problem and reporting in on their progress (to the rest of their TrustNet). Each member of a TrustNet is also an open server that allows incoming connections from clients that bring in new transactions or requests for information.

Quote
I got really confused about your use of the term network peers here. Sometimes it seems to mean intra-NT peers. Other times it seems to mean inter-NT relationships.

And the statement "they will be putting" is completely nebulous. I understand why they will be putting together a block. I just have no idea who they are? Is there a single delegate for the NT? Do the members of the NT collaborate together? How do they share data? Who is responsible for resending the block every few seconds?

This time it means intra-NT peers. Cheesy Again, terribly sorry about the word confusion. The draft is still really rough but I have it clearly in my head, it just doesn't always come out very clear.
Individual servers of a TrustNet will pass any received transactions immediately on to their fellow TN members. They are connected to 4-5 out of the potential 100 TN members so as not to spam each other out and have 94-95 extra open connections that aren't necessary. Each member is aware of which 100 users are in their TN, what their IP addresses are, and so on, they are just not always connected to every one.

So, this is how it will happen for a new transaction:

1. One member of the TN receives an incoming transaction from a client.
2. This member passes this transaction, unadulterated, on to the 4 or 5 TN members they are connected to.
3. These 4-5 members pass this transaction on to the other 3-4 TN members that they are connected to. (and so on)
4. Every 15 seconds, one member of the TN will be randomly selected* to put a block of new transactions (a block because to do it for every transaction would be a terrible waste of resources, especially when there may be hundreds of transactions per second) together that are signed by the TrustNet's private key. Then this block of signed transactions is passed along back to every TN member in the same manner as a new incoming transaction. One member is selected to do this so that the TN presents a united, identical block to other TNs. This allows infiltrators to be spotted more easily trying to insert bad spends into transaction blocks, or other nefarious things.
5. Each TN member then signs this block with their own private key and passes it along to each other, separate TN that they are connected to as well as "the cloud" as described earlier.

* - Randomly selected by a function that everybody agrees on, so at the time it happens, everyone will know who it is that got selected.

Quote
It seems like there is a delegation pattern at work here. But then you say "Each peer knows the address of every peer in their network in case Something Really Bad™ is happening (all 4 or 5 peers are disconnected, or all 4 or 5 appear to be doing shady stuff, or something similar)" which implies each peer is monitoring his NT peers, not trusting them.

I'm really confused.

Everybody is assumed to be trustworthy until they prove that they aren't. For an infiltration attack to have any chance of succeeding, the infiltrator must act as a trusted member of the (overall) network first. Computers are doing the trusting, not humans. That would be far too much work for any person to keep up with. I'll talk more about this in response to your other post.

Quote
Again, when I said "account(ing) part of your trust network peer," I was thinking about the delegate pattern. Supposed you delegated *all* the 1) receiving of NT member's transactions, 2) validation of NT member's transactions, 3) transaction block broadcasting and receiving, 4) validation and recording of inter-NT transactions. This could easily be done using only the power of an iPhone.

If you are not delegating the above 4 things to some "trusted" delegate node, then I'm totally confused about the dynamics of your NT group of nodes. If each member does these things individually without trusting the other members, then the batching, signing, and sending seems redundant.

Yes you aren't seeing things the way I see them in my head. WHY THE HELL NOT? Tongue Mining proof-of-work proves that, until you do something bad, at least you can be trusted more than someone who doesn't mine because you are putting time, money, and effort into creating currency for the economy. Proof-of-work still has a very important purpose in the EnCoin design.

An iphone could be a good client, but not a good server as I described earlier.

Quote
I don't mean to be dense, but I'm totally baffled by this last paragraph.

We got all the way here, talking about a distributed system for trusted and verified transaction accounting. Never once did you mention any necessity for *mining* in order to guarantee transaction validity. Validity was guaranteed through transaction block signing (consensus notarization).

What on earth does mining secure? The only thing I see that it can possibly protect is the reward system for mining. This system seems to operate completely independently. In actually, it doesn't seem to secure the transaction system. It seems to rely on the consensus relationships of the underlying transaction system to frustrate subverting the mining reward system.

Again, I'm baffled.

Third paragraph of section 4 on network trusts/trustnets:

"As TNs continue to mint coins and agree on transactions with the rest of the network, the TrustNet Rating (TNR) of that TN will increase."

This has been in the proposal in one form or another since the beginning, so I'm not sure why you're confused. If your trust could increase just by being a "yes man" and agreeing with everybody else, you have not put any effort or money into the system, just a bit of network data. People are not individually making any of these decisions, it is all done by computer. There has to be a real, hard cost associated with gaining trust, or a sybil attack is much easier.

Quote
I thought the mining system was a way to optimize monetary policy. Where "optimize" means, expand or contract the money supply as appropriate to maintain coin value stability. That is a hard problem and worth my time to think about.

On the other hand, levying a tax on every transaction and using *mining* as justification for redistributing this tax among miners... Well that seems to be an unnecessary problem to solve at all. At best it's a marketing problem. That's not at all where I want to waste my mental energy.

You really seem to take offense that some of the users involved in this theoretical project are out to make a profit. Mining secures the network (albeit in a much more indirect manner than bitcoin), miners need to get paid. It's rather simple. I'm not going to rehash my reasoning for why there are incentives for being more trusted or whatever else at this point. And the tax is destroyed, so miners do not get that money. It is there to help the economic contraction, or to create new demand (continued security!) in times of economic stability.

I'll respond to the other post later, this took a bit out of me. Wink

Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 26, 2011, 11:49:03 PM
 #96

Well I'm glad we are in agreement. Thank you, I don't have any further business with Encoin.

Yes, having people actually vote to determine economic policy is certainly the best way. I mean, it works for politics after all.

And I love how you take my concession that it is impossible to maintain the exact rate of energy used per encoin as some kind of proof that the currency will fail. It is childish and willfully ignores the 5 pages of discussion in this thread.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
September 27, 2011, 12:12:43 AM
 #97

How? I don't see how this is possible.

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.

----

The whole concept is based upon Arbitrage. The instantaneous buying and selling of something in different markets. In this case, we want to buy ENC in the "electrical market" using dollars and sell them in the ENC marketplace for dollars. (Your currency may vary) The tendency toward a fixed value is based upon the self-interest of the participating humans. They only participate if it seems profitable. If it appears unprofitable the humans do nothing.

So specifically, if a human thinks he can generate excess ENC for less dollars of electricity than the dollars he can IMMEDIATELY sell the ENC for, he begins mining. If he thinks it will cost more dollars of electricity than the ENC are worth, he stops mining. It's an intellectual gamble like in any financial marketplace. You have to put your dollars at risk to play.

---

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. 100% of the existing nodes decide that all transactions in that block are valid. Then they lock that block into the chain forever. There is also no standard 50 BTC award. Transaction accounting is NOT rewarded. For this discussion, just pretend I can prove that it's a secure process.

So in my version of the ENC system, mining is a completely optional process to that of transaction accounting. Mining DOES NOT secure transaction accounting.

The process works like I've discussed in this thread.

1) Every transaction has a X% tax that is destroyed. This provides a baseline tendency that reduces the ENC supply. Transaction are grouped into 10 min blocks like with bitcoin.

2) Mining is optional and can be run by anyone at any time. Mining generates new ENC transactions through a proof-of-work concept similar to bitcoin. The main differences more complicated ENC generation rules, and the process for varying the proof-of-work's difficulty.

Mining takes place in the 10 minute interval after the previous (consensus created) transaction block. The proof-of-work can be solved at increasing difficulty levels, leading to increasing rewards.

The transaction generation rules are as follows:

If the miner solves the proof-of-work at the (current+0) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) ZERO additional reward for the miner.

If the miner solves the proof-of-work at the (current+1) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) (Total Tax)/2 as reward for the miner.

If the miner solves the proof-of-work at the (current+2) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) (Total Tax)*2 as reward for the miner.

Mining is a competitive process. Whoever generates the proof-of-work transaction with the highest difficult in the 10 minute window wins. If there is more than one at the highest difficulty, the first wins.


Difficult is algorithmically adjusted for the next 10 minute period based upon the results of the previous.

If ZERO mining transactions were submitted, the current difficulty is adjusted (-1).
If a current+0 transaction wins, the current difficulty remains unchanged (0).
If a current+1 transaction wins, the current difficulty is adjusted (+1).
If a current+2 transaction wins, the current difficulty is adjusted (+2).

---

As far as I can tell this tends to cause the following dynamics.

If the current difficulty causes higher electrical cost than the dollar value of ENC, there is minimal incentive to try and add new ENC coins to the system. As such the Tax will be lost, tending to slightly inflate the dollar value of ENC. The difficulty will also be reduced, tending to slightly lower the electrical cost of ENC.

If the current difficulty causes near equivalent electrical cost to the dollar value of ENC, anyone with a transaction in the prior block, has interest in mining for their tax reimbursement. This means the appropriate monetary action was to do nothing. (No tax penalties)

If the current difficulty causes less electrical cost than the dollar value of ENC, then there is a momentary arbitrage opportunity. No tax will be lost. New ENC will be added tending to slightly deflate the dollar value of ENC. The difficulty will also be increased, tending to slightly increase the electrical cost of ENC.
 
---

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?
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 27, 2011, 02:14:05 AM
 #98

This post does not inspire confidence at all.

Perhaps it should inspire some confidence that I have had defense to this type of attack in mind in designing every facet of my proposal.

Quote
You know of course that the Sybil attack was one of the prime motivations for developing the wacky proof-of-work calculation. The logic goes, if we are going to have a group of anonymous peers, and we need to vote on things...

See above. In simple terms, where Bitcoin and Encoin differ is that Bitcoin associates hash power with trust whereas Encoin associates hash power times time with trust. Because the value of time is a recorded figure (in the form of points of trust), this figure can be changed when there is proof that it needs to be changed.

In simple equations:
trust = hash
trust = hash * time

In bitcoin, an attack with >50% computational power can only be thwarted by more computational power. This means, as long as the attacker feels like attacking, the network is interrupted and may be permanently damaged thereafter.
In encoin, an attack with >50% trust can be thwarted by setting the time factor to 0. This means, the attacker gets one shot at doing something bad when they have enough trust, then that shot is over unless they reinvest hundreds of thousands or millions of dollars and a whole lot more time.

To "hack" the trust time, an attacker would need the private keys of hundreds or thousands of users. In which case they could just spend all of their money and cause havoc anyway. To "hack" the hash, an attacker need only overtake several pools, or invent some kind of hardware that performs hashes magnitudes more quickly than typical hardware, or wait for the network to contract such as when the btc award halves.

If the average amount of trust in the working network is 180, the attacker essentially has to put 180 times the effort TIMES >50% of the number of network trusts into disrupting the network. For one shot. In bitcoin, the attacker can keep on shooting and there is nothing that anyone can do about it.

Is it any clearer now why I think a system of trust is far superior?

Quote
Fortunately for you, EnCoin has relationships between non-anonymous trusted parties that investigate scamming, broadcast notices to the public, ban the scammers, and report them to the appropriate authorities. If the authority in your trust network can't do this, why on earth would you "trust" them?

As I mentioned before, a sybil attack relies on gaining trust before performing an attack. If this "authority" pretended to be trustworthy, everyone would think they're trustworthy. Until they're not. Since Encoin relies on heavy amounts of electricity to gain this trust, it is very difficult and hard to come by. It cannot be forged. It can be revoked completely by consensus.

EDIT: I skimmed over the first sentence when replying. The non-anonymous relationships are nowhere near what you suggest. The non-anonymous relationships only refer to ip address->wallet (tied to user trust) relationships. With bitcoin, you never have any idea of who you're dealing with. There is no recorded history other than transactions.

Quote
The fact that you consider these possible (but implausible) attacks on your proposed system shows that your basic consensus (100% agreement) mechanism is non-existent.

Validity means a transaction is 100% in compliance with the rules of the system. There is no negotiation involved. No vote is ever required.

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.

Quote
ATTACK: TrustNet tries to pay itself too much money

This should be trivially detected and prevented by *every* other TrustNet. It is either a defect in that peer, or fraud committed by the peers owner. The defective/fraudulent TrustNet entity and all its users should be banned until trusted humans determine which problem it is.

There is no need for humans to do anything but run their honest clients.

Quote
ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)

WTF? How can any group of peers abuse the TrustNet's trust? The TrustNet was supposed to be the party everyone else was trusting? The only way to attempt a double spend is to simultaneously submit two conflicting transactions to different TrustNets. Both would be accepted and each would "race" the other to see which got "51% Trust" first.

Every user that is a member of a TrustNet (one of many) gets the private key to that TrustNet, so they can pretend to sign something that the TrustNet did not agree to sign.

Quote
That whole concept is STUPID and IRRESPONSIBLE.

It only is if you can't possibly get away with it. If there were no safety checks for keeping in mind that there is no guarantee that everyone is honest, then these types of attacks would cause major issues with the network.

Quote
Both transactions are part of a single common attempt at fraud. This should be detected in 100% of the cases, by 100% of compliant Trust Networks.

What if a malicious entity controls more than 50% of the trust networks? How will clients know that there is a problem if more than half the network says "everything's fine here, move along."

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)

Quote
REALLY! You even consider this a possibility?

If I didn't, the network couldn't be secure.

Quote
Arrg! If this can't be immediately detected by 100% of compliant Trust Networks and broadcast system-wide, then really there is no reason for anyone to trust your EnCoin at all.

Again, you say "compliant" with a naive understanding. Compliant is what the network says is compliant. Honest networks will detect it, but honest networks can't guarantee that they will be connected to every user. If a user is connected to only dishonest networks, how will he know that the rules have been broken? The dishonest networks certainly aren't going to volunteer this information. But, because it will be obvious that the network has split in half based on half of the normal trust in the primary block (the dishonest networks have set the trust to the honest networks to zero in their version of the new encoin), the client can demand the transaction log for the last block and discover that account balances do not match up with the transactions (or they will refuse to send it). So now the client knows empirically that something is massively wrong. In bitcoin, everyone except the people who got screwed will continue on, none-the-wiser. Save maybe a forum rant or two where the evidence is hard to verify.

Quote
I mean really, you are claiming that periodically your system "cools down" to reach a common consensus (100% agreement) point. At that point 100% of the Trust Networks agree on 100% of the account balances. You are saying that somehow 51% of the networks can conspire to change a balance or submit a fraudulent transaction and the other 49% either can't detect and/or can't prevent this fraud?Huh

See above. The network will reach a consensus among honest TrustNets. They cannot force dishonest TrustNets to agree to something they are intentionally not agreeing to. The network will fork between honest and dishonest TrustNets. This is by design. Cut out the cancer.

Quote
Any single compliant network must be able to validate the compliance of every other network. If they can't there is zero point in anyone trusting even an honest "Trust Network".

They can. But they can't make a client be connected to them to let them know.


I think you have a gross misunderstanding of the client/server model here (which was probably clarified in my last long post). I'm sure it's more my fault than anything by not being completely clear in the proposal. But TrustNets are a replacement for pools, I thought that was made obvious. Regular users of the bitcoin network are not involved in any pools. The people in TrustNets are being paid in the form of new demand for currency by the expansion of the network or gradual destruction of existing currency. Their services are not just to make coins, but to secure the network. Secure, secure, secure.

Perhaps some of my design decisions will make a little bit more sense now.

Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
September 27, 2011, 02:50:25 AM
 #99

By the way, everything I have stated that is not in regards to economic policy could have been done with bitcoin.

The goal of Encoin's economic policy is not to facilitate a large transfer of wealth from late adopters to early adopters. It is to provide a stable medium of exchange. While unpredictable future events (fusion power for one) could slightly devalue the currency, it is absolutely nowhere even close to even being remotely in the same solar system as what someone with 25k or 100k or any large sum of bitcoins could do to the network that is based solely on scarcity with no inherent value to back it up. Please keep that in mind before dismissing encoin out of hand because you don't think that it can work.

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

johnj
Full Member
***
Offline Offline

Activity: 154


View Profile
September 27, 2011, 04:54:15 AM
 #100

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.

1AeW7QK59HvEJwiyMztFH1ubWPSLLKx5ym
TradeHill Referral TH-R120549
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!