Bitcoin Forum
November 05, 2024, 04:10:06 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [30] 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 »
  Print  
Author Topic: MC2: A cryptocurrency based on a hybrid PoW/PoS system  (Read 195184 times)
digicoin
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000



View Profile
May 24, 2013, 09:33:33 AM
 #581

Why not do the same thing as how Litecoin was released?

I am new here. My stupid question is: "How was LiteCoin released?" "Is there any trick to prevent it from being cloned like crazy?"
digicoin
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000



View Profile
May 24, 2013, 09:36:13 AM
 #582

I think you need a wiki to discuss design issues. The white paper discusses several independent ideas.

It would be better to make designs more modular. This allows for modular contributions from people with specific expertise.

Make a wiki containing a wish list of features and linking to independent articles describing the design of each feature.

In my opinion, altcoins only have competitive potential to the extent that they can absorb new ideas from outsiders. Bitcoin is too far advanced to allow this. Many altcoins don't facilitate this either, out of both (a) get-rich quick greed and (b) egoism.


I love the idea.  Smiley
coblee
Donator
Legendary
*
Offline Offline

Activity: 1654
Merit: 1351


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
May 24, 2013, 10:09:05 AM
 #583

Why not do the same thing as how Litecoin was released?

I am new here. My stupid question is: "How was LiteCoin released?" "Is there any trick to prevent it from being cloned like crazy?"

Here's the quote from the main litecoin thread:

Quote
We have come up with a plan that we believe is most fair.  Some previous coins were released without Windows binaries or without source code; we consider this as unfair as it is unsafe.

We released the source code and binaries ahead of time... 3 days before launch.  People had time to compile the source and run the client on their machines against the Litecoin testnet.  So people were able to make sure everything was working well before the launch.  We also had a poll so that people can vote for a launch time that best suits them.  At the time of the launch (Oct 12 03:00 GMT), we released the genesis hash and everyone started mining at the same time.  All it took was a simple change in the config file in order to mine the real coin instead of the testnet coin.

cryptrol
Hero Member
*****
Offline Offline

Activity: 637
Merit: 500


View Profile
May 24, 2013, 10:56:31 AM
 #584

Quote
...as unfair as it is unsafe...
+1

I am extremely paranoid so, I always build from source, so this keeps me out from being an "early adopter" for almost _all_ coins.
Although maybe taco is afraid of someone else hoarding the netcoin concept before the official launch, people is so mad lately that they mine and trade _everything_ . So someone could get the code and build a new coin in no time.

Having said that I would prefer having the code before launch, and take the (small) risk I mentioned before.
Justsumdude
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 24, 2013, 11:02:34 AM
 #585


Here's the quote from the main litecoin thread:

Quote
We have come up with a plan that we believe is most fair.  Some previous coins were released without Windows binaries or without source code; we consider this as unfair as it is unsafe.

We released the source code and binaries ahead of time... 3 days before launch.  People had time to compile the source and run the client on their machines against the Litecoin testnet.  So people were able to make sure everything was working well before the launch.  We also had a poll so that people can vote for a launch time that best suits them.  At the time of the launch (Oct 12 03:00 GMT), we released the genesis hash and everyone started mining at the same time.  All it took was a simple change in the config file in order to mine the real coin instead of the testnet coin.

Nice way of doing it, too bad it didn't catch on.
digicoin
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000



View Profile
May 24, 2013, 11:46:50 AM
 #586

Practically, releasing source code is not good way to go at the moment  because new coin based on NetCoin can appear at any time. We need to build trust.
Michael_S
Sr. Member
****
Offline Offline

Activity: 278
Merit: 251


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
May 25, 2013, 04:05:26 AM
 #587

Is it possible to design a coin's confirmation time interval (=block generation interval) to be more predictable than with today's Poisson process?
I think yes.

Bitcoin & Co have "n" minutes AVERAGE confirmation time based on a given difficulty that is fixed for a certain time, hence the poisson distribution.

Now the idea: After a new block has been created, the difficulty is first higher than the "nominal difficulty" (= "currently valid reference difficulty"), then it will fall with time, maybe reaching the "reference" difficulty value after the design value of "n" minutes, and then it will fall even further afterwards, if still no block was generated. The function of difficulty decrease can be designed somewhat arbitrarly, e.g. a linear function (or linear in log scale) with a steepness to be defined. So the difficulty would e.g. look like a "sawtooth" function, with a new "tooth" starting at each newly generated block.

This way, the probability of having a new block created very shortly after a block has just been created is significantly decreased compared to today. On the other hand, if a block has not been generated after "n" minutes, if will become increasingly likely that a block will be created "very soon".

In other words, the probability distribution function for the block generation interval (which currently has its average at "n" minutes) would become much narrower, hence confirmation intervals would become more predictable.


Further thoughts:

* Such mechanism could encourage miners to submit their mining results "in advance", i.e. even if current difficulty is yet a little too high to be accepted, maybe in 10 or 15 seconds the difficulty would have dropped and then the block would become valid, UNLESS by that timer another miner has submitted a block with a higher difficulty.
So the block acceptance rule could be this: At any time, blocks that have been sent out are accepted as soon as their difficulty is higher than the currently valid difficulty (which falls acc. to the sawtooth function).

* How to avoid spam of blocks, i.e. that miners submit blocks too long in advance, just in case they are still the best blocks once the difficulty has decreased to surpass this block's difficulty threshold? Idea: A miner must invest something (e.g. 10% (rounded upwards to full satoshis) of the current block reward, or a function of last block's tx fees) to submit a mined candidate block A. If this block A is the one that will finally be taken into the blockchain, the miner gets its investment back. However, if this block A is not taken because another miner submits a higher-difficulty block B before the difficulty falls so low that the block A could be accepted, then the investment of the miner A for block candidate A is lost and goes to the successful miner of block B as extra reward. This mechanism avoids that miners submit block candidates too frequently and too early in time, because each submission that is not accepted means a "lost investment". Of course, this also means that miners may follow different algorithms in terms of "optimum block submission times" of mined blocks to maximize the expenses, as a side effect.

Does this idea make sense to be considered in a new coin...?

PS: ...or does this just mean that block generation will concentrate more around the "n" minute times after the last generation, thereby increasing number of orphans in the network in an undesirable way? (...maybe this idea was not that good after all...?)

aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
May 25, 2013, 07:18:22 AM
 #588

Now the idea: After a new block has been created, the difficulty is first higher than the "nominal difficulty" (= "currently valid reference difficulty"), then it will fall with time, maybe reaching the "reference" difficulty value after the design value of "n" minutes, and then it will fall even further afterwards, if still no block was generated. The function of difficulty decrease can be designed somewhat arbitrarly, e.g. a linear function (or linear in log scale) with a steepness to be defined. So the difficulty would e.g. look like a "sawtooth" function, with a new "tooth" starting at each newly generated block.
Unfortunately there is no way to accurately measure time in bitcoin network. All you have are timestamps in block headers which can be easily cheated.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
dolfcao
Member
**
Offline Offline

Activity: 98
Merit: 10



View Profile WWW
May 25, 2013, 09:06:14 AM
 #589

what's going on now?

RealCoin: RRUfzu9qeUU9qAeHJARpGVqDQsXEU7u4d9
RealCoin Mining Pool: www.realcoin.org:18888
My personal website: www.needdo.com
efx
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
May 25, 2013, 09:16:00 AM
Last edit: May 25, 2013, 10:00:10 AM by efx
 #590

Who knows? Only tacotime I assume, I hope he has some people working on this with him.


"We have come up with a plan that we believe is most fair.  Some previous coins were released without Windows binaries or without source code; we consider this as unfair as it is unsafe.

We released the source code and binaries ahead of time... 3 days before launch.  People had time to compile the source and run the client on their machines against the Litecoin testnet.  So people were able to make sure everything was working well before the launch.  We also had a poll so that people can vote for a launch time that best suits them.  At the time of the launch (Oct 12 03:00 GMT), we released the genesis hash and everyone started mining at the same time.  All it took was a simple change in the config file in order to mine the real coin instead of the testnet coin."

+1!

Tacotime, I hope you will consider using a similar release system (if it doesn't overly jeopardize the IP behind the MC2/netcoin concept).

I really think the conditions of release have an underestimated long-term effect on confidence. Anyways, MC2 is one of the few new concepts I'm keeping my eyes on and looking forward to.
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
May 25, 2013, 09:47:39 AM
 #591

I think you need a wiki to discuss design issues. The white paper discusses several independent ideas.

It would be better to make designs more modular. This allows for modular contributions from people with specific expertise.

Make a wiki containing a wish list of features and linking to independent articles describing the design of each feature.

In my opinion, altcoins only have competitive potential to the extent that they can absorb new ideas from outsiders. Bitcoin is too far advanced to allow this. Many altcoins don't facilitate this either, out of both (a) get-rich quick greed and (b) egoism.


I love the idea.  Smiley

What is the best free wiki platform?

I'm thinking "Cryptocurrency Design" as the name of the wiki.

Like http://www.reddit.com/r/cryptocurrency to keep it neutral, but strictly limited to theoretical design issues.
The forums are a mess. Everything is discovered, forgotten, and rediscovered often in bastardized form.

digitalindustry
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


‘Try to be nice’


View Profile WWW
May 25, 2013, 10:43:31 AM
 #592

I think you need a wiki to discuss design issues. The white paper discusses several independent ideas.

It would be better to make designs more modular. This allows for modular contributions from people with specific expertise.

Make a wiki containing a wish list of features and linking to independent articles describing the design of each feature.

In my opinion, altcoins only have competitive potential to the extent that they can absorb new ideas from outsiders. Bitcoin is too far advanced to allow this. Many altcoins don't facilitate this either, out of both (a) get-rich quick greed and (b) egoism.


I love the idea.  Smiley

What is the best free wiki platform?

I'm thinking "Cryptocurrency Design" as the name of the wiki.

Like http://www.reddit.com/r/cryptocurrency to keep it neutral, but strictly limited to theoretical design issues.
The forums are a mess. Everything is discovered, forgotten, and rediscovered often in bastardized form.






this is a great idea , even a Cyrptocurrency forum , as I said before , that will allow organization of such ideas , would suffice .

it will only take a few of the innovative leaders to go there and promo it , then most of the Cryptocurrency environment would follow , this forum would be left with the spamcoin releases , but only because they did not want organization , but to be fair as well it is  "bitcointalk.org" so ya know. ....  its probably actually better left for well… Bitcoin talk.

- Twitter @Kolin_Quark
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
May 25, 2013, 10:50:29 AM
 #593

I think you need a wiki to discuss design issues. The white paper discusses several independent ideas.

It would be better to make designs more modular. This allows for modular contributions from people with specific expertise.

Make a wiki containing a wish list of features and linking to independent articles describing the design of each feature.

In my opinion, altcoins only have competitive potential to the extent that they can absorb new ideas from outsiders. Bitcoin is too far advanced to allow this. Many altcoins don't facilitate this either, out of both (a) get-rich quick greed and (b) egoism.


I love the idea.  Smiley

What is the best free wiki platform?

I'm thinking "Cryptocurrency Design" as the name of the wiki.

Like http://www.reddit.com/r/cryptocurrency to keep it neutral, but strictly limited to theoretical design issues.
The forums are a mess. Everything is discovered, forgotten, and rediscovered often in bastardized form.






this is a great idea , even a Cyrptocurrency forum , as I said before , that will allow organization of such ideas , would suffice .

it will only take a few of the innovative leaders to go there and promo it , then most of the Cryptocurrency environment would follow , this forum would be left with the spamcoin releases , but only because they did not want organization , but to be fair as well it is  "bitcointalk.org" so ya know. ....  its probably actually better left for well… Bitcoin talk.


Forums allow the same topic to be hashed over repeatedly. A wiki format makes this less likely.
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


‘Try to be nice’


View Profile WWW
May 25, 2013, 04:28:54 PM
 #594

I think you need a wiki to discuss design issues. The white paper discusses several independent ideas.

It would be better to make designs more modular. This allows for modular contributions from people with specific expertise.

Make a wiki containing a wish list of features and linking to independent articles describing the design of each feature.

In my opinion, altcoins only have competitive potential to the extent that they can absorb new ideas from outsiders. Bitcoin is too far advanced to allow this. Many altcoins don't facilitate this either, out of both (a) get-rich quick greed and (b) egoism.


I love the idea.  Smiley

What is the best free wiki platform?

I'm thinking "Cryptocurrency Design" as the name of the wiki.

Like http://www.reddit.com/r/cryptocurrency to keep it neutral, but strictly limited to theoretical design issues.
The forums are a mess. Everything is discovered, forgotten, and rediscovered often in bastardized form.






this is a great idea , even a Cyrptocurrency forum , as I said before , that will allow organization of such ideas , would suffice .

it will only take a few of the innovative leaders to go there and promo it , then most of the Cryptocurrency environment would follow , this forum would be left with the spamcoin releases , but only because they did not want organization , but to be fair as well it is  "bitcointalk.org" so ya know. ....  its probably actually better left for well… Bitcoin talk.


Forums allow the same topic to be hashed over repeatedly. A wiki format makes this less likely.

point taken , but both are needed.

- Twitter @Kolin_Quark
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
May 26, 2013, 06:27:14 PM
Last edit: May 26, 2013, 06:50:56 PM by tacotime
 #595

Sorry, finally getting some time to spend sitting down and thinking about this for a couple hours.

But the way to mitigate the attack is similar to what you described (I'm not sure why you described it as the square root of the difficulties?), but just assign a blockchain score of:
block=1{summation}block=n of  (PoW Difficulty in Block 1 * (PoS Difficulty in Block 1)^-1) + ... + (PoW Difficulty in Block n * (PoS Difficulty in Block n)^-1)
Huh I don't get this. This is the weight for the total blockchain right?

PoS difficulty is the price of a ticket in terms of % of total coins available. The price is adjusted to sell a constant # of tickets. If the PoS Difficulty is low (tickets are cheap), then only a small fraction of total coins are participating in the lottery. The chain should be penalized for this. Your formula rewards the attacker for lowering PoS Difficulty, making the problem worse not better.

Again I suggest you use:
  
block=1{summation}block=n of  (PoW Difficulty in Block 1)^0.5 * (PoS Difficulty in Block 1)^0.5 + ... + (PoW Difficulty in Block n)^0.5 * (PoS Difficulty in Block n)^0.5
Yeah, now I get it.

Quote
Quote
The only time you can get absolute certainty that a double spend can succeed is with 51% PoW and 51% PoS.  But you suspect there is a flaw in this logic...
Nothing to lose sleep over. Even though your logic is flawed, it does not reflect a fundamental flaw in your design. One chain will always be either better, equal to, or worse than another chain. The algorithm evaluates proof chains to decide this.

One group's chain controls a fraction x PoW and a fraction y PoS. The other group then has corresponding fractions 1-x PoW and 1-y PoS. The groups use their resources to construct long proof chains. Let f be a function evaluating the proof in a chain constructed using a PoW and PoS pair over a long time span. Of course PoW outcomes are random, but let's just ignore that to keep things simple.

We must have f (x, y) > f (1-x, 1-y) or f (x, y) = f (1-x, 1-y) or f (x, y) < f (1-x, 1-y). That is the first group wins, it is a tie, or the first group loses. The winning group gets complete control over which txns enter PoW blocks. The losing group becomes completely irrelevant.

f (x, y) = f (1-x, 1-y) describes a boundary on 0 <=x <=1 and 0 <=y <=1. If one group (good or bad) is on this boundary and adds on just a little bit of hashing power or a little bit of stake, then this group wins.

Bitcoin uses the boundary x = 0.5
My ideal boundary is y = 0.5   (that's what you approach as the number of signatories per block increases)

Your boundary needs to simulated because of the two difficulties.

But if we ignore that (only matters over long intervals anyway) and make an additional assumption, we can calculate it.

Here's the assumption:

You are including invalidated empty blocks in the block chain. If these empty blocks contribute to proof just like normal blocks, a 51% PoW attacker can select the winning chain, even with 0% stake. This makes PoS close to pointless. To avoid this, I'm going to assume that the empty blocks do not contribute to proof at all.

Then:

A PoW block contributes to proof iff it has at least 3 stake votes.
Proof Creation Rate = (Rate at Which Group Creates PoW Blocks) * (Probability Group Controls 3, 4, or 5 Stake Votes)

Probability Group Controls 3, 4, or 5 Stake Votes is a binomial distribution with Pr (X>=3) for a binomial distribution with parameters n=5 and p=y for group 1 and p=1-y for group 2. http://en.wikipedia.org/wiki/Binomial_distribution

Pr (X>=3) = Pr (X=3)+Pr(X=4)+Pr(X=5)= 10y³(1-y)²+5y⁴(1-y)+y⁵ for group 1

Rate at which Group 1 creates PoW blocks is x*(total hash rate of both groups / PoW difficulty).
So we have,
Group 1 Proof Creation Rate = f(x,y) = (10y³(1-y)²+5y⁴(1-y)+y⁵) * (x) * (total hash rate of both groups / PoW difficulty)
Group 2 Proof Creation Rate = f(1-x,1-y) = (10(1-y)³(y)²+5(1-y)⁴(y)+(1-y)⁵) * (1-x) * (total hash rate of both groups / PoW difficulty)
The two groups are tied if
(10y³(1-y)²+5y⁴(1-y)+y⁵) * (x) * (total hash rate of both groups / PoW difficulty) = (10(1-y)³(y)²+5(1-y)⁴(y)+(1-y)⁵) * (1-x) * (total hash rate of both groups / PoW difficulty)

Solving for x gives us the boundary

x = -6y⁵+15y⁴-10y³+1 on 0<=y<=1  

In table form:

x                y

1           0
0.99144   0.1
0.94208   0.2
0.83692   0.3
0.68256   0.4
0.5           0.5
0.31744   0.6
0.16308   0.7
0.05792   0.8
0.00856   0.9
0           1

So yes, you probably weren't aware that you could win with 90% stake and 0.9% work. But why is that a problem?

I guess it's not really a problem.

If we include total number of stakeholder votes in a separate weighting function, you may also be able to attenuate double spends by any stakeholder less than 51%.  Such a weighting function might be described as
block=1{summation}block=n of  (Stakeholder Votes in Block 1) + ... + (Stakeholder Votes in Block n)

The attacker wishes to double spend and the exchange requires three secured (3+ Yea votes) blocks for confirmation.  Now, he must mine a chain in secret and achieve 3 or more secured blocks.  In the meantime, the main chain must have three secured blocks to actually get the money to the exchange.  However, this honest chain will have great difficulty actually achieving valid blocks without the help of the attacker, who can not dump his alternative chain onto the network unless the sum of his votes on his dishonest chain are greater than for the honest chain.  The attacker must now wait a long time to achieve his double spend attack, although it's still not impossible.

With two weighting functions, you then end up with four conditions of the network when there are two chains in comparison with one another represented by (0,0), (0,1), (1,0), and (1,1).  The first value indicates the condition of chain A being preferred over chain B using the first weighting metric, and the second value indicates the condition of chain A being preferred over chain B using the second weighting metric.  For both conditions that are mixed, how should the main chain be selected?  Is there some way you can think of to integrate the two weighting functions without further complicating things?

You are correct in that invalidated blocks will not contribute to the blockchain for the calculation above.  They do, however, contribute the following:
1) Stakeholder tickets used within them are invalidated and their invalidation is included in the blockchain (can't spend stakeholder tickets twice).
2) Entropy from the block header hash is used to calculate ticket selection/lottery (as the block header still represents actual work).

There is a new attack that I just thought of if you force stakeholders to use their tickets when the lottery calls them.  A PoW miner can submit blocks to the network full of garbage and use them to destroy PoS tickets, because the group of stakeholders in the next block will be sure to invalidate this block.  This is a problem.  How can this be mitigated?  You could return the stakeholder tickets (so long as they actually voted) and let them be used again sometime in the future to validate a different block.  Non-reporting stakeholder tickets should still be destroyed.

This makes sense.  PoS miners should not be penalized for voting correctly on the previous block when the present block is garbage.

edit:
There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block.  It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially.  There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way.

I need to think about this some more, can't think of an easy solution off the top of my head.  Perhaps just to have these stakeholders vote on the last block and then sign the one in which they are included in once it is submitted to the network is enough.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Etlase2
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
May 26, 2013, 07:24:27 PM
 #596

edit:
There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block.  It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially.  There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way.

I need to think about this some more, can't think of an easy solution off the top of my head.

Stop relying on PoW for any part of network security.

tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
May 26, 2013, 09:28:38 PM
 #597

edit:
There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block.  It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially.  There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way.

I need to think about this some more, can't think of an easy solution off the top of my head.

Stop relying on PoW for any part of network security.

Eh.  It's okay for security, but I really like it in there for 1) distribution of new coins and 2) keeping consistent network timing for blocks.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
May 27, 2013, 02:58:53 AM
 #598

edit:
There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block.  It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially.  There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way.

I need to think about this some more, can't think of an easy solution off the top of my head.

Stop relying on PoW for any part of network security.

Eh.  It's okay for security, but I really like it in there for 1) distribution of new coins and 2) keeping consistent network timing for blocks.

Real life is hitting me in the face, so sorry if I don't respond to the longer point today. On this short point I want to agree with you.

1) I agree that its necessary for distributing coins according to community norms. However, I think that after 2 years or less, PoW distribution will be controlled by big companies no matter what. Thus, it doesn't make sense to spread PoW distribution across more than a few years to me. Whatever though, I'm not going to make a stink over it.

2) I agree. Timing, in my view, is why we would need small, but not negligible PoW rewards. Predictable timing using a secure, decentralized pure PoS system seems very hard to me. The only way I've figured out to do pure PoS safely implies a very large variance in block times. If combined with secure 0-conf txns, maybe timing variance is okay. Still, it's complicated and the design's too difficult for me to explain (that means I don't understand it well). Nothing good comes of biting off more than you can chew. Pure PoS should be shelved right now.

[tl;dr] Taco's plan of 1% inflation or a little more with rewards about evenly divided between PoS and PoW is good enough. I just would prefer we move to 1% inflation in a few years rather than a few decades.

  
igba
Member
**
Offline Offline

Activity: 111
Merit: 10



View Profile
May 27, 2013, 09:36:21 PM
 #599

take your time on this one, I'd hate to see this end up like 90% of cryptos, even If we have to wait till the end of the summer I'm sure most people following this thread would like this coin to succeed.
achillez
Hero Member
*****
Offline Offline

Activity: 878
Merit: 1000


View Profile
May 28, 2013, 02:43:19 AM
 #600

Amen!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [30] 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 »
  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!