Topic: MC2: A cryptocurrency based on a hybrid PoW/PoS system - page 48. (Read 195188 times)
I would also like to be added to any PM mailing list that may form for this coin. I am fairly new to cryptocurrencies, but am digging into it quick. Currently looking into setting up an exchange or other related site and I would like to help out with this any way I can. This looks like a promising project.
I can also offer the coordination of Mandarin translation and proof reading for translations.
I really like the way this is heading.. I think with all the community involvement and thought going into this, the launch will be something to see!
You can count on me for any help needed in translations to spanish, and website/forum development.
Same here - I'll help out where possible. Also can do some development for you.
I was digging through hash algorithms today from the SHA-3 contest, and I saw a couple that were disqualified... not due to insecurity, but due to "performance issues". One in particular stood out:
"FSB is slower than traditional hash functions and uses quite a lot of memory, which makes it impractical on memory constrained environments. Furthermore, the compression function used in FSB needs a large output size to guarantee security."
Sounds like potential to me.
http://en.wikipedia.org/wiki/Fast_Syndrome_Based_Hash
https://www.rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb
As for the name... I still have an aversion to *coin names, but if we're stuck with it, netCoin is generic and simple enough to encourage adoption from the mundanes.
"FSB is slower than traditional hash functions and uses quite a lot of memory, which makes it impractical on memory constrained environments. Furthermore, the compression function used in FSB needs a large output size to guarantee security."
Sounds like potential to me.
http://en.wikipedia.org/wiki/Fast_Syndrome_Based_Hash
https://www.rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb
As for the name... I still have an aversion to *coin names, but if we're stuck with it, netCoin is generic and simple enough to encourage adoption from the mundanes.
I'm looking at lots of different hashes right now, there are lots of different ones to choose from and I'll try to implement as many interesting ones as possible.
When you do launch, ping me over PM. Would be fun to help you work out the kinks, I'll throw a few hash at it.
I was digging through hash algorithms today from the SHA-3 contest, and I saw a couple that were disqualified... not due to insecurity, but due to "performance issues". One in particular stood out:
"FSB is slower than traditional hash functions and uses quite a lot of memory, which makes it impractical on memory constrained environments. Furthermore, the compression function used in FSB needs a large output size to guarantee security."
Sounds like potential to me.
http://en.wikipedia.org/wiki/Fast_Syndrome_Based_Hash
https://www.rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb
As for the name... I still have an aversion to *coin names, but if we're stuck with it, netCoin is generic and simple enough to encourage adoption from the mundanes.
"FSB is slower than traditional hash functions and uses quite a lot of memory, which makes it impractical on memory constrained environments. Furthermore, the compression function used in FSB needs a large output size to guarantee security."
Sounds like potential to me.
http://en.wikipedia.org/wiki/Fast_Syndrome_Based_Hash
https://www.rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb
As for the name... I still have an aversion to *coin names, but if we're stuck with it, netCoin is generic and simple enough to encourage adoption from the mundanes.
I'm looking at lots of different hashes right now, there are lots of different ones to choose from and I'll try to implement as many interesting ones as possible.
At that point though, I think you may as well just resolve to use a less computationally and bandwidth intensive system such as the one (probably) employed by OpenCoin.
I wouldn't be so strict about it. Even bitcoin has some checkpoint in its source. It is not really a big deal to checkpoint system once in a few months. Every client could even do it for its own and just don't accept another blockchain if it rewrites more than few months of history. If it can make PoS and blockchain reduction feasible I think its worth it. I was thinking that instead of people casting a real vote, they will vote with their wallets, and having a dynamic generation. And let me explain, what i think it may be a good idea, but i am not sure about the technical difficulties involved (i need to check the source code of the current crypto coins when i will have some time).
1. A block is generated every 10 seconds for fast approval of transactions
2. At first every block will give 10 or 50 or whatever value.
3. After some time (let's say 1 million of coin have been generated or after 6 months), the value generated by a new block is proportional with the transactions made since the last block have been found. Let's say, as an example, that when a new block is found 1% of the coins used since the last block is generated. So if 100 coins have changed hands since the last block, the new block will generate 1 new coin. This will generate new coins only based on the usage of the coin, and i think it will be a good thing, also considering that the transaction will be approved faster and so one of the problem of the current crypto coins will be solved.
1. A block is generated every 10 seconds for fast approval of transactions
2. At first every block will give 10 or 50 or whatever value.
3. After some time (let's say 1 million of coin have been generated or after 6 months), the value generated by a new block is proportional with the transactions made since the last block have been found. Let's say, as an example, that when a new block is found 1% of the coins used since the last block is generated. So if 100 coins have changed hands since the last block, the new block will generate 1 new coin. This will generate new coins only based on the usage of the coin, and i think it will be a good thing, also considering that the transaction will be approved faster and so one of the problem of the current crypto coins will be solved.
The problem with such a system is that an attacker will generate tons of spam just to get a greater reward in an upcoming block.
1) Transaction times - Starbucks, gas station and grocery lineups (something many of us deal with daily) are long enough as it is, can you imagine the patience of people in a lineup to wait for your 10 minute cryptocoin transaction to go through?! Or imagine on black Friday, you need to purchase that $1,000 flatscreen and BestBuy makes you wait for 6 confirmations (~1hour) before approving the transaction. We BADLY need transaction times to be 30 seconds or less, ideally on par or better than credit cards. This IMO is the #1 hurdle to mass adoption. Who the heck wants to wait around to pay for something? And which business owner wants less customers because they are too frustrated waiting around to buy something?
I think this can be solved as follows:
Rather than having a single blockchain, use a hierarchy (L0 : L1 : L2 : L3 ...) of blockchains. Then we could for example set
Difficulty of Level (i + 1) = alpha * (Difficult of Level i)
where alpha is for example equal to 0.25
This would mean the time to generate a block at level i + 1 would also be approximately equal to (the time to generate a block at level i) * alpha.
When a new block is found on level i, we start a new blockchain on level i + 1 using the hash of the new block of level i as the genesis block of the new blockchain of level i + 1. The transactions are processed in the same way as before in the blockchain of the highest level. To generate a block at level i, all transactions that are included in the blockchain at level i + 1 should be combined into a single transaction at level i.
This has the following advantages:
- Automated laundry: When all transactions at level i + 1 are combined in a single transaction and the previous blockchain at level i + 1 is discarded, it is no longer possible to discern individual transactions at level i + 1. If this is done at multiple levels, it gets even better.
- Automated blockchain compression: If the higher level contains multiple transactions between A and B, these are compressed into a single transaction. If A sends coins to B and B sends the same amount of coins to C, it is not even necessary to include B in the transaction at all.
- Reduced performance requirements for the point-of-sale devices. Since the blocks at higher levels are easier to generate, the devices that generate blocks here can be simpler.
This way, we get both shorter transaction times for POS devices, while avoiding excessive blockchain size.
If the different levels use the same algorithm, the reward for finding a block can be based on the relative difficulty at the different levels.
Feel free to point out any obvious flaws in this idea. If some of the dinosaurs roaming around here know this idea has been proposed before, I'm really sorry for suggesting it.
Edit: So, I think this should solve, or at least reduce the negative effect of the following problems in your list too:
8 ) SatoshiDice blockchain pollution - Please figure out a way that the blockchain doesn't get polluted with 5 million .00001 transactions per day. Please discourage ridiculous micro transactions. Micro transactions are definitely wanted, but not millions of them by the same entity. What % of the blockchain now is satoshidice garbage ? Maybe have a transaction fee that is high enough to prevent excessive number of small transactions.
9) The Mega Blockchain problem - Is there any viable way to prevent the blockchain from growing into Terabytes of size? Can we not archive it every X years or every X gigabytes or something ? I mean, sure storage is cheap these days and bandwidths are getting higher, but think like a Chinese government in loooong timespans. In 200 years, how large might the blockchain be? 5 billion petabytes ? Hopefully we won't hit a technological wall of storage or bandwidth along the way resulting in the crash of the currency because no more transactions can be added to the blockchain, because every user would have to own their own private data center.
9) The Mega Blockchain problem - Is there any viable way to prevent the blockchain from growing into Terabytes of size? Can we not archive it every X years or every X gigabytes or something ? I mean, sure storage is cheap these days and bandwidths are getting higher, but think like a Chinese government in loooong timespans. In 200 years, how large might the blockchain be? 5 billion petabytes ? Hopefully we won't hit a technological wall of storage or bandwidth along the way resulting in the crash of the currency because no more transactions can be added to the blockchain, because every user would have to own their own private data center.
I'm not sure I really follow. If you lower the difficulty to mine the side chain, and all the miners hop onto this new chain, you'll run into a lot of orphans. If you running multiple chains at the same time of variable difficulty (eg a binary tree of blockchains), you run into the issue of massive amounts of network bandwidth required with arguably no enhancement of security (what's to stop an attacker from making his own binary tree of block chains and then dumping it on the network?).
Maybe make the coin a consistent generation coin depending upon contribution of processing power, not like the current lottery system so that pools are not very popular and thus a couple of big pools don't control the whole thing.
Hope that made sense
Hope that made sense
Makes perfect sense. Good idea imo.
There's not really an easy way to solve this, and this problem is mostly already solved using a normal blockchain by using P2Pool anyway.
Hi tacotime,
Finally, somebody working on a coin that substantially improves upon bitcoin, and is not just another copy/paste clone with a few changed parameters. I'm not a cryptologist or a programmer, but I'd like to provide some real world input where IMO bitcoin is failing and where improvement is seriously needed for mass adoption or longevity of the currency is to become a reality. Here's a few things to consider improving:
1) Transaction times - Starbucks, gas station and grocery lineups (something many of us deal with daily) are long enough as it is, can you imagine the patience of people in a lineup to wait for your 10 minute cryptocoin transaction to go through?! Or imagine on black Friday, you need to purchase that $1,000 flatscreen and BestBuy makes you wait for 6 confirmations (~1hour) before approving the transaction. We BADLY need transaction times to be 30 seconds or less, ideally on par or better than credit cards. This IMO is the #1 hurdle to mass adoption. Who the heck wants to wait around to pay for something? And which business owner wants less customers because they are too frustrated waiting around to buy something?
I'm trying now to get it down to 4 minutes or less. Faster may be possible, but it will involve playing with the protocol on the testnet and getting the block down to something very small, like 8 KB, and hoping that can propagate across the network appropriately in seconds.Finally, somebody working on a coin that substantially improves upon bitcoin, and is not just another copy/paste clone with a few changed parameters. I'm not a cryptologist or a programmer, but I'd like to provide some real world input where IMO bitcoin is failing and where improvement is seriously needed for mass adoption or longevity of the currency is to become a reality. Here's a few things to consider improving:
1) Transaction times - Starbucks, gas station and grocery lineups (something many of us deal with daily) are long enough as it is, can you imagine the patience of people in a lineup to wait for your 10 minute cryptocoin transaction to go through?! Or imagine on black Friday, you need to purchase that $1,000 flatscreen and BestBuy makes you wait for 6 confirmations (~1hour) before approving the transaction. We BADLY need transaction times to be 30 seconds or less, ideally on par or better than credit cards. This IMO is the #1 hurdle to mass adoption. Who the heck wants to wait around to pay for something? And which business owner wants less customers because they are too frustrated waiting around to buy something?
Quote
2) Network Security - Please don't make the same mistake as bitcoin and use a single TCP port that can be shut down on a firewall in less than 1 minute. Imagine the currency gets too popular and government somehow passes a law to shut it down under some false pretense (ZOMG its used by Al-queida and drugdealers!). Bitcoin can be shut down overnight by blocking TCP port 8333 at all Tier1 ISPs. The counter argument of the bitcoin developers is extremely poor, in that, there's other open source software such as TOR or i2p that bitcoin could function through... but that assumes that bitcoin would even survive the TCP port shutdown attack which is pretty much cost free to the government. Look at Mtgox.. it gets DDOS'ed for a few hours and bitcoin value crashes by 70%+. Now imagine a firewall rule that blocks bitcoin at the Tier1 ISP backbone level, and 95% of the users who don't have a clue about Tor or i2P (or 99.9999% of non-tech users), and you can bet the currency will crash to near ZERO and be finished. In other words, include proper network layer security from day 1 ! This is far more important that trying to figure out how to prevent complex 51% attacks. This costs ZERO money for the government and ISPs to do, every ISP already has firewalls as part of their core and edge infrastructure. And if you think the USA would never pass such a law to enact the crushing of a popular competing currency... well then think about the other 190+ countries on this planet that may pass such laws with far less hesitation.
Well, the solution I guess would be to start on a default port and then scan subsequent ports in some order until it finds one with traffic permissible and use that. The just transmit your port to known nodes and propagate it across the network.Quote
3) ASIC security - Using 8 different sCrypt algorithms somewhat randomly is an improvement, but what's to prevent mining software from rejecting anything but type 1 Scrypt algo block and mining only those? This would result in at least 8 different types of ASICs needed, sure, but not ASIC proof, IMO. Alternatively, you could still create an ASIC that could direct mining to one of 8 segments of the ASIC and still be much faster than GPU mining. This would mean you have a much more complex ASIC design and 1/8th the potential crunching power, but still many orders of magnitude better than PC/GPUs/FPGAs. So my suggestion is please don't think like Bill Gates that 640K or.. 8 algos should be enough. Why not make it 4096+ of them and outright discourage any kind of ASIC... ever. My concern with ASICs isn't even somebody trying to make a lot of money faster than others, but rather government 3 letter agencies throwing 1 Billion printed dollars at the problem creating an ASIC farm, and killing the coin altogether. The NSA just built a 2 billion dollar data center in 2012. With a Homeland security budget in the Trillions, 1 billion is like petty cash, and you can bet that preventing the US dollar from collapse against popularity gaining crypto currencies is a homeland security issue.
I'm working on a new algorithm that incorporates all the hash algorithms together via scrypt. At some point too adding hash algorithms will slow things down for CPU or GPU because you'll overflow the instruction cache I imagine, so you have to evaluate all the hash functions individually and see how many clock cycles it takes to compute each one, and the same thing for scrypt memory transfer.Quote
4) The 5th grader problem - Let's face it, Joe 6 pack can't do basic math, he is not smarter than a 5th grader, even less so in 3rd world countries where education is seriously lacking. DON'T fractionalize the coins into ridiculous numbers of decimal places, or make people use 8 different fractional acronyms mBTC, satoshi's etc. The major problem with bitcoin from gaining mass adoption is that it is seriously not adhering to the KISS (keep it simple stupid) principle. You think in 10 years, your average person is really going to understand or want to deal with .000004 bitcoins? Please consider the Brazilian solution. Brazil in the past few decades had severe bouts of high inflation in their "Real" currency... after the inflation got too high, i.e. the number of ZEROs on the notes got too be too many they simply issued a new currency and said something like 1,000 of the old Real's are now worth 1 of the new issued Real's. This didn't solve the high inflation issues of course, but it's a simple solution that could solve trying to deal with .24056794 bitcoins to buy a loaf of bread.[/b]
Well, you could just make a box in your wallet that is based on the SI prefix that you cycle through, for instance cNTC, mNTC, etc to get a denomination close to a dollar. Clicking the button would automatically change the value everywhere in the wallet. I can't control what the value of the coin will be, so this is probably the best answer. The everyone can just click in the wallet to change it every 6 years when it increases by an order of magnitude or whatever.Quote
5) Anonymity Improvements - I'm not sure why satoshi only went 1/2 way to make the bitcoin anonymous. Clearly he didn't go far enough in the eyes of many. There are now all kinds of academics studying the bitcoin blockchain and trying to figure out who has how many coins (including satoshi himself), and where they live. Look, blockchain.info can identify a user's aproximate location and map it: http://blockchain.info/tx/58d961336f14d3c8305dfe193c5e00ac00a3a9de21aa605ee701da714fb1657c
Please prevent identifying user's IP and thus geo location. I know IPs aren't in the blockchain, but they can and are apparently being collected by major nodes - this could be mitigated by having bitcoin work within a TOR like system. Probably there are many other anonymity improvements that can be made, I am just mentioning the most glaring one for me.
They already can't identify my IP in bitcoin; I check blockchain.info constantly when I make transactions and I have never seen my IP come up as a trafficking node. You can easily just transmit a transaction over TOR already if you really want to, though (it'll come out of the exit node to a bitcoin node). I guess it'd be desirable to have a few nodes with connection ports of 80 to easily accept these tx, too.Please prevent identifying user's IP and thus geo location. I know IPs aren't in the blockchain, but they can and are apparently being collected by major nodes - this could be mitigated by having bitcoin work within a TOR like system. Probably there are many other anonymity improvements that can be made, I am just mentioning the most glaring one for me.
Quote
6) Wishlist - I honestly don't understand 80% of the items on this bitcoin improvement wish list, but seriously consider implementing the best ones because from my understanding, once a coin gets too popular, the risk of making any major changes becomes ever bigger, and thus innovation will stall. In other words, get it right from the get go as much as possible, because hardforks are not popular. https://en.bitcoin.it/wiki/Hardfork_Wishlist
I'm trying my best. A number are already being addressed, such as the use of an alternative light ledger system to complete downloading of the blockchain.Quote
7) Hardforks - Why are hardforks so hard on the system? Chrome and IE now force automatic updates upon 100's of millions of users, with little seeming repercussions... why not do the same with your coin? If auto-updates are not somehow possible, then establish a coin-holiday, or several a year (say 1 major update opportunity per quarter), where all clients/miners must update to the new patch-level whose details of course would be pre-announced. Also, if you can, think of a way to establish an Emergency change system in case something goes horribly wrong by accident.
An update system that simply prompts the user would be desirable, yes, but it may also make the chain less secure, for instance if someone found a way to redirect the DNS of the update on the target computer to a version that was illegitimate. You'd have to be careful and use some kind of validation method like public key encryption.Quote
8 ) SatoshiDice blockchain pollution - Please figure out a way that the blockchain doesn't get polluted with 5 million .00001 transactions per day. Please discourage ridiculous micro transactions. Micro transactions are definitely wanted, but not millions of them by the same entity. What % of the blockchain now is satoshidice garbage ? Maybe have a transaction fee that is high enough to prevent excessive number of small transactions.
This is easily solvable by just keeping the per KB fee high enough.Quote
9) The Mega Blockchain problem - Is there any viable way to prevent the blockchain from growing into Terabytes of size? Can we not archive it every X years or every X gigabytes or something ? I mean, sure storage is cheap these days and bandwidths are getting higher, but think like a Chinese government in loooong timespans. In 200 years, how large might the blockchain be? 5 billion petabytes ? Hopefully we won't hit a technological wall of storage or bandwidth along the way resulting in the crash of the currency because no more transactions can be added to the blockchain, because every user would have to own their own private data center.
You can decentralize block storage (eg only keep blocks that contain transactions to and from your block address) and store the block hashes and a ledger. Then persons can share blocks and eventually reconstruct the blockchain. However, it's of interest to keep the total chain in at least one location, but by decentralizing like mentioned you can significantly reduce the overall world storage used.Quote
10) Democratic voting of interest rates - I'm not sure this is such a good idea, with humanity being what it is. The lowest common denominator would always win, and this is rarely the best decision that can be made. This is readily evident in today's government formations. Nobody goes on a campaign trail announcing massive necessary spending cuts, increases in taxes or interest rates, because none of the constituents in their right mind want less money. Likewise, if people could vote on things like interest rates, they would always vote for whatever is best for them right now, not for the survival of the system in the long run. Thus, I think satoshi had it right in that the problem with fiat is that it is controlled by humans, and the advantage of bitcoin is that everyone can trust an intelligent algorithm. As the philosophers proclaim (paraphrase): Genius does not belong the majority, it is the inherent attribute of the rarest of human. .... fortunately for us, we can work hard at making a genius algorithm.
You can partially mitigate this by enforce a minimum reward for both PoS and PoW, and also a maximum, and also by allowing only small changes allowed per year. It's similar to allowing the difficulty to only adjust a little bit each round instead of letting swing violently. I agree with your criticism of PPC model but I don't see how it applies to system I described. Block reward int this design should be proportional to used stake (think of it as gaining interest on reserves) so you don't get any instant gain by keeping other miners of network.
As for energy efficiency. I think you should always analyze incentives of single rational miner. If you adopt difficulty target modification by stake single miner effective hashrate in this system is (hash rate) x (accumulated coin age). If we impose some kind of limit on maximum coin age (for example 1000 blocks) then rational miner should mine once in 1000 blocks because then he gets most efficiency in terms of energy consumption. If everyone follows same strategy then we would get miners searching for blocks in turns and great share of available hashing power would be idle most of the time. Energy consumption should be much lower than in bitcoin and I think it is enough.
Well, you may be able to make an overall reduction in the amount of energy if you also restrict the reward based on coin age (I don't think difficulty modification is enough, as people with higher hash rates can afford to mine blocks at lower coin ages). But, it depends on whether you want to have a barrier of entry for mining based on stake, which is something I don't particularly like. I like the idea of having the bulk of coin generation in PoW, which has a lower barrier of entry.As for energy efficiency. I think you should always analyze incentives of single rational miner. If you adopt difficulty target modification by stake single miner effective hashrate in this system is (hash rate) x (accumulated coin age). If we impose some kind of limit on maximum coin age (for example 1000 blocks) then rational miner should mine once in 1000 blocks because then he gets most efficiency in terms of energy consumption. If everyone follows same strategy then we would get miners searching for blocks in turns and great share of available hashing power would be idle most of the time. Energy consumption should be much lower than in bitcoin and I think it is enough.
Quote
The more I think the more I am convinced that pure PoS chain is not possible without checkpoints. Problem arise from the fact that as block generating activity is not computationally expensive attacker can always simulate network from genesis block. In his network he would have 100% of stake and could easily outrun honest network in generating longest proof chain. Another problem with PoS is that you need to be able to check validity of stake in every block since genesis. That means you have to be able to retrieve account balance state at any point in the past. This makes it impossible to make a nice trimmed database of account balances. This problem could also be mitigated with checkpoints.
At that point though, I think you may as well just resolve to use a less computationally and bandwidth intensive system such as the one (probably) employed by OpenCoin. There's nothing that fundamentally shows that PPC or whatever chain with some PoW uses less power; it's entirely theoretical. One may argue that PPC and friends are even worse, because they encourage attacks on pools by making the benefit to the miner instantaneous (per round difficulty adjustments). PPC basically them turns it "Keep as many other miners off the network as possible" coin because reward is based on difficulty.
Even if you make stake a considerable factor in your ability to solve blocks, you still end up with a billion PoW miners at the end of the day hopping onto pools with large amount of stake and using lots of energy, so that solution looks rather naive.
I agree with your criticism of PPC model but I don't see how it applies to system I described. Block reward int this design should be proportional to used stake (think of it as gaining interest on reserves) so you don't get any instant gain by keeping other miners of network. Even if you make stake a considerable factor in your ability to solve blocks, you still end up with a billion PoW miners at the end of the day hopping onto pools with large amount of stake and using lots of energy, so that solution looks rather naive.
As for energy efficiency. I think you should always analyze incentives of single rational miner. If you adopt difficulty target modification by stake single miner effective hashrate in this system is (hash rate) x (accumulated coin age). If we impose some kind of limit on maximum coin age (for example 1000 blocks) then rational miner should mine once in 1000 blocks because then he gets most efficiency in terms of energy consumption. If everyone follows same strategy then we would get miners searching for blocks in turns and great share of available hashing power would be idle most of the time. Energy consumption should be much lower than in bitcoin and I think it is enough.
The more I think the more I am convinced that pure PoS chain is not possible without checkpoints. Problem arise from the fact that as block generating activity is not computationally expensive attacker can always simulate network from genesis block. In his network he would have 100% of stake and could easily outrun honest network in generating longest proof chain. Another problem with PoS is that you need to be able to check validity of stake in every block since genesis. That means you have to be able to retrieve account balance state at any point in the past. This makes it impossible to make a nice trimmed database of account balances. This problem could also be mitigated with checkpoints.
1a. Do you want Netcoin to be clone-proof, i.e., "Attack of the CoinClones", i.e., FTC and CHN, CHNcoin making it's mining debut today, FTC listing on btc-e IPO last night.
OR
1b. Netcoin encourages competition, i.e., may the best Netcoin win.
Thinking broadly into the future.
Mining adoption through GUI P2P.
=========================
- Draw API from exchanges, make trading window in NTCGUI.
--- Traders then drawn closer to mining, miners then drawn closer to trading.
--- Mining and Trading then become the Crypto paradigm more globally. (We see many one/many GUI interfaces born recently, logically condense these).
+ blockchain bloat/network traffic decreased
+ confirmation times and transaction times decreased.
=========================
- Add to GUI ability to see (k,m)/hash/s delivered as a fiat figure, then ticker="time to destruction of fiat"
Just for funzies.
OR
1b. Netcoin encourages competition, i.e., may the best Netcoin win.
Thinking broadly into the future.
Mining adoption through GUI P2P.
=========================
- Draw API from exchanges, make trading window in NTCGUI.
--- Traders then drawn closer to mining, miners then drawn closer to trading.
--- Mining and Trading then become the Crypto paradigm more globally. (We see many one/many GUI interfaces born recently, logically condense these).
+ blockchain bloat/network traffic decreased
+ confirmation times and transaction times decreased.
=========================
- Add to GUI ability to see (k,m)/hash/s delivered as a fiat figure, then ticker="time to destruction of fiat"
Just for funzies.
This is the one i'm looking for... registering xD
I'll try to get through all the pages of questions today so I have more time to write the whitepaper later this weekend.
You can now chat on CryptoCat in the room netcoindev; I'm AFK there right now but I should be in and out on a regular basis.
Dedicated forum is forthcoming.
If you want to use CryptoCat anonymously and simply, just download the Tor browser bundle and install CryptoCat plugin on the bundled FireFox browser. CryptoCat was decided over freenode because it's so much easier to achieve anonymous service as compared to freenode (downside is there is no chat moderator; please don't abuse the channel).
You can now chat on CryptoCat in the room netcoindev; I'm AFK there right now but I should be in and out on a regular basis.
Dedicated forum is forthcoming.
If you want to use CryptoCat anonymously and simply, just download the Tor browser bundle and install CryptoCat plugin on the bundled FireFox browser. CryptoCat was decided over freenode because it's so much easier to achieve anonymous service as compared to freenode (downside is there is no chat moderator; please don't abuse the channel).
[quote I will not use a premine to fund it, though. The method I would consider to be the most desirable would be to rout the fee to a series of addresses (a new one every 3 or 6 coin months or so) and then pay the kickstarter contributors dividends extending directly from the network fees. This could continue for a few years, then the fees would be given to miners.
Thank god for no premine, and excellent idea about dividents payout.
If you're working with Python then list me as someone who may occasionally contribute code. What languages are you working with?
Probably C++, but I'll put you down as a potential dev.You're absolutely right. This should be on Kickstarter. Why not?
As far as Kickstarter,
I will consider crowd-sourcing this. I will not use a premine to fund it, though. The method I would consider to be the most desirable would be to rout the fee to a series of addresses (a new one every 3 or 6 coin months or so) and then pay the kickstarter contributors dividends extending directly from the network fees. This could continue for a few years, then the fees would be given to miners.
First, I just want to say that I applaud Tacotime's acknowledgement of how a coin should be released especially with all these silly copycat alt coins that provide nothing novel being spammed almost daily now. Litecoin has shown the advantages of alternative hashing algorithms, but I also concur that a more in depth look at optimizing a coin for GPU mining above all else is key. If GPU mining is able to be protected as the best way to mine a coin then this provides the best decentralization as gamers will always be a huge distribution of hashing power whereas ASICs and FPGAs will always be skewed towards a relatively few individuals/groups with significant capital (not that GPU mining farms are impossible just that even a few thousand GPU farms will pale in comparison to the gaming community).
Now, while just optimizing the hashing algorithm provides a useful trait for a new coin, I suggest that we take this opportunity and add a few additional key traits to the new coin to provide utility to the community well beyond any current cryptocurrency. In order of importance I suggest the following additional key features:
Distributed Exchange
Distributed exchange is perhaps the killer feature that everyone is talking about often with unrealistic expectations. Obviously we cannot solve the problem of converting fiat directly into cryptocurrency, but I believe we can provide a decentralized exchange mechanism that only relies on outside trusted parties for a final withdrawal or deposit of fiat. My suggestion has two main features. First, we incorporate the colored coins idea (https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1) to allow any outside party to create and sign particular coins as having some additional meaning (in the fiat use case that would be some amount of USD for instance). Second, we create a new type of transaction that posts an offer to the network to exchange some number of new(whatever our new currency is called)coins for a certain number of colored coins properly signed by an entity or set of entities or vice versa. Once the network sees offers that match, a transaction is recorded in the block chain that atomically transfers ownership to each party. (TODO optimize incentives for miners to match offers well through transaction fees etc.)
I would also like to see a way to exchange with other cryptocurrency directly, but this has many additional hurdles such as requiring all nodes or at least miners to keep other block chains in memory and possible denial of service attacks from people accepting offers and not sending the BTC or LTC agreed upon.
I'd love to have it, but have no idea how to implement it as previously mentioned. If another party wishes to via a peripheral system such as a plug in, that's fine, but I don't plan on it being in the client at launch.Now, while just optimizing the hashing algorithm provides a useful trait for a new coin, I suggest that we take this opportunity and add a few additional key traits to the new coin to provide utility to the community well beyond any current cryptocurrency. In order of importance I suggest the following additional key features:
Distributed Exchange
Distributed exchange is perhaps the killer feature that everyone is talking about often with unrealistic expectations. Obviously we cannot solve the problem of converting fiat directly into cryptocurrency, but I believe we can provide a decentralized exchange mechanism that only relies on outside trusted parties for a final withdrawal or deposit of fiat. My suggestion has two main features. First, we incorporate the colored coins idea (https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1) to allow any outside party to create and sign particular coins as having some additional meaning (in the fiat use case that would be some amount of USD for instance). Second, we create a new type of transaction that posts an offer to the network to exchange some number of new(whatever our new currency is called)coins for a certain number of colored coins properly signed by an entity or set of entities or vice versa. Once the network sees offers that match, a transaction is recorded in the block chain that atomically transfers ownership to each party. (TODO optimize incentives for miners to match offers well through transaction fees etc.)
I would also like to see a way to exchange with other cryptocurrency directly, but this has many additional hurdles such as requiring all nodes or at least miners to keep other block chains in memory and possible denial of service attacks from people accepting offers and not sending the BTC or LTC agreed upon.
Quote
Built in P2Pool type mining option
The P2Pool project epitomizes the distributed nature and serves as an important bulwark against a few popular pools from having a huge influence on block chains. I suggest we incorporate this option directly into the client. This also will give users a no hassle option to mine and receive coins out of the box without dealing with pool registration and the risk of them being hacked.
That is probably doable, but I'm not too knowledgable on P2P. I would like to have at least a few pools open at launch, that are started from the testnet.The P2Pool project epitomizes the distributed nature and serves as an important bulwark against a few popular pools from having a huge influence on block chains. I suggest we incorporate this option directly into the client. This also will give users a no hassle option to mine and receive coins out of the box without dealing with pool registration and the risk of them being hacked.
Quote
Built in GPU mining option
I suggest we bundle and integrate a graphical interface such that novice users can easily mine with their GPU with just the normal official client. Combined with the above P2Pool suggestion this should further democratize mining making it as user friendly as possible to novice users.
Depends on the availability of a GPU miner at launch.I suggest we bundle and integrate a graphical interface such that novice users can easily mine with their GPU with just the normal official client. Combined with the above P2Pool suggestion this should further democratize mining making it as user friendly as possible to novice users.
Quote
Zerocoin anonymization
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf
While this may yet be too computationally and space intensive for now, I think we should at least consider the possibility of implementing this state of the art crypto work. It is going to be presented at the top academic conference in computer security this May. Read the paper for details, but the gist is that you can truly anonymize the coins such that no one can match the input and outputs of transactions. The main disadvantage it has for bitcoin is that the protocol would have to be accepted by all the users, but if we incorporate this by default in the client from the start we solve that problem. There is some concern about how heavyweight the crypto is so that will have to be considered.
As you mentioned, implementation of ZeroCoin would be so resource intensive that it'd probably kill the chain. The tradeoff is anonymity versus pseudononymity, and presently I'm okay with the latter.http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf
While this may yet be too computationally and space intensive for now, I think we should at least consider the possibility of implementing this state of the art crypto work. It is going to be presented at the top academic conference in computer security this May. Read the paper for details, but the gist is that you can truly anonymize the coins such that no one can match the input and outputs of transactions. The main disadvantage it has for bitcoin is that the protocol would have to be accepted by all the users, but if we incorporate this by default in the client from the start we solve that problem. There is some concern about how heavyweight the crypto is so that will have to be considered.
Quote
0-confirmation double spend resistance
The normal defense against a double spend is to wait for a number of confirmations such that an attacker will have to have close to or more than 51% of the hashing power of the network. This is a very strong guarantee and works well for transactions of any amount, but comes at the cost of waiting for at least 1 block. For asynchronous transactions such as online purchases where product is eventually shipped after some delay this is almost no cost at all, but in the scenario where a user wants to use bitcoin like cash for an in store purchase and walk out with merchandise, this wait time greatly exceeds that of a 1 second credit card processing wait. This is as far as I know a novel idea that I came up with to partially address wait time. A transaction with zero confirmations can easily be double spent. I propose that if multiple transactions are floating in the network waiting to be confirmed into the next block and there are conflicts among them (double spends) that as long as each transaction by itself would be valid that instead of choosing one the network writes both into the block and destroys the coins involved. While the merchant would still lose the coins so would the attacker removing the incentive to double spend. Now of course for large transactions one would still be ill advised to accept 0 confirmations, this destroys the incentive for a casual theft of small amounts. I think this could be especially useful for payment processors like bitinstant when people use it on their phones to pay for food or beer as if they left immediately after, there is a significant delay before anyone would be aware of the zero confirmation double spend.
I am also available to contribute some time to design/programming. I think this should be a significant undertaking with as many people involved as possible to really create a significant contribution to the cryptocurrency community. Anything halfhearted or just an incremental improvement will not make much difference. I'd rather not have a slew of alternative currencies that slowly build on each other, but rather a significant leap forward with real testing and new features.
Let me know if anything is unclear. I'll try to answer any questions although most of these ideas are preliminary so lots of work in finalizing an actual working implementation is yet to be done. I do believe that all these suggestions are quite practical if we have enough programmers volunteer to create and test them.
Nathaniel
Working on this. Zero conf spending is probably a bad idea still, but I may be able to get it down to 4 minutes or less (forthcoming; again, there are tradeoffs).The normal defense against a double spend is to wait for a number of confirmations such that an attacker will have to have close to or more than 51% of the hashing power of the network. This is a very strong guarantee and works well for transactions of any amount, but comes at the cost of waiting for at least 1 block. For asynchronous transactions such as online purchases where product is eventually shipped after some delay this is almost no cost at all, but in the scenario where a user wants to use bitcoin like cash for an in store purchase and walk out with merchandise, this wait time greatly exceeds that of a 1 second credit card processing wait. This is as far as I know a novel idea that I came up with to partially address wait time. A transaction with zero confirmations can easily be double spent. I propose that if multiple transactions are floating in the network waiting to be confirmed into the next block and there are conflicts among them (double spends) that as long as each transaction by itself would be valid that instead of choosing one the network writes both into the block and destroys the coins involved. While the merchant would still lose the coins so would the attacker removing the incentive to double spend. Now of course for large transactions one would still be ill advised to accept 0 confirmations, this destroys the incentive for a casual theft of small amounts. I think this could be especially useful for payment processors like bitinstant when people use it on their phones to pay for food or beer as if they left immediately after, there is a significant delay before anyone would be aware of the zero confirmation double spend.
I am also available to contribute some time to design/programming. I think this should be a significant undertaking with as many people involved as possible to really create a significant contribution to the cryptocurrency community. Anything halfhearted or just an incremental improvement will not make much difference. I'd rather not have a slew of alternative currencies that slowly build on each other, but rather a significant leap forward with real testing and new features.
Let me know if anything is unclear. I'll try to answer any questions although most of these ideas are preliminary so lots of work in finalizing an actual working implementation is yet to be done. I do believe that all these suggestions are quite practical if we have enough programmers volunteer to create and test them.
Nathaniel
I will add you to the potential dev list.
Jump to: