Bitcoin Forum
June 15, 2024, 12:21:31 AM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How about skipping the pumpndump phase completely?  (Read 406 times)
Cryddit (OP)
Legendary
*
Offline Offline

Activity: 924
Merit: 1129


View Profile
December 21, 2013, 07:52:23 PM
 #1


I'm not yet getting ready to launch a coin, I'm still in development.  But I'm getting excited about it. 

That said, it's a bit different and I'd like to hear people's reaction to some of the differences.

1.  No "Mining" -- doesn't matter how fast you can perform hashes, it's purely proof-of-stake.  Coins created will be split among those who run full nodes in proportion to the number of "mature" coins they keep in a "hot wallet" at that node. If there are widespread objections to this point I may alter the plan to award, say, 5% or 10% of the coins via mining.  But changes in mining difficulty will never affect the number or approximate timing of proof-of-stake blocks.

2.  No initial period of obscenely rapid growth in money supply and no long-term upper limit on money amount -- One million coins distributed among MANY users at block zero, 3% inflation thereafter. (Note, this means only about 30K coins produced in the first year, or 7 rounds per hour, half-a-coin per round. )  Initial distribution may be something as banal as creating txouts that have the same keys as txouts selected from the bitcoin or litecoin (or both) blockchains, and putting 5 coins in each created txout.  Selection criteria would be having been created by transaction rather than as a coinbase, and being at least a certain amount (amount to be determined by the goal of distributing one million initial coins).

3.  Native support for "colored coins" and a built-in distributed exchange for different kinds of coins.

4.  Distributed mixing.  Within the client, you can designate the outputs from a given tx as "private" -- Your client will then undertake to mix the coins for you and they will disappear from that tx and, after some delay, reappear under "mix output".  There's a special coin color that represents coins "in the mix" -- the client simply buys some on the distributed exchange with your money, then uses them to buy back money in the next block.  The distributed exchange transactions have inputs and outputs from everyone doing mixing; each round the price for mixcoins is calculated that allows the greatest number of coins to be traded, and all buyers and sellers get the same price.  So, on average mixing costs nothing. In practice, because the coins "float" against each other you may make a small profit or loss.  If you have a WHOLE LOT of coins that need mixing, the time required to mix your coins may vary with the amount to be mixed and the amounts other people want to mix at the same time, because your client will be putting coins through the mix a few at a time proportional to the mix volume.  It won't ever put coins into the mix that represent more than about ten percent of the volume being mixed that round.

5.  It has a way to scale.  If the number and size of tx threaten to overwhelm a blockchain, it can split into multiple blockchains.  In a high volume scenario, it could be split into 24 "channels" -- with each full node belonging to one "channel" and having to keep track of and verify only a bit more than 1/12 of the total number of transactions.  Each channel would have one blockchain in common with each other channel, which would handle all the common 2-party transactions.  Then there'd be one blockchain in common to all the channels, to handle the uncommon more-than-2-party transactions such as mixes and distributed exchanges.
In this scenario, that makes 552 blockchains shared by 2 channels each, plus one blockchain shared by everybody.  Each "channel" would have to be listening to 23 of the former and the latter.  This should, I hope, keep bandwidth and storage requirements for full nodes possible, while allowing scaling up to "VISA level volume." 

Pages: [1]
  Print  
 
Jump to:  

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