I don't see it posted yet... How porn links and Ben Bernanke snuck into Bitcoin's codeHere's a little-known quirk of cyber currency Bitcoin: There are coded messages hidden in the ledger that track bitcoin transactions. Most are innocuous, but this week, the discovery of a malicious transmission filled with porn links set the Bitcoin community abuzz. http://money.cnn.com/2013/05/02/technology/security/bitcoin-porn/ |
|
|
|
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_Hashhttps://www.rocq.inria.fr/secret/CBCrypto/index.php?pg=fsbAs 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. |
|
|
|
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.
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.
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
Makes perfect sense. Good idea imo. This is very important! 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. 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. 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. 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. 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/58d961336f14d3c8305dfe193c5e00ac00a3a9de21aa605ee701da714fb1657cPlease 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. 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. 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. 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. 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. 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. 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. |
|
|
|
Reward algorithm: int64 GetProofOfWorkReward(unsigned int nBits)
{
CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
CBigNum bnTargetLimit = bnProofOfWorkLimit;
bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());
// ppcoin: subsidy is cut in half every 64x multiply of difficulty
// A reasonably continuous curve is used to avoid shock to market
// (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
//
// Human readable form:
//
// nSubsidy = 100 / (diff ^ 1/6)
CBigNum bnLowerBound = CENT;
CBigNum bnUpperBound = bnSubsidyLimit;
while (bnLowerBound + CENT <= bnUpperBound)
{
CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
bnUpperBound = bnMidValue;
else
bnLowerBound = bnMidValue;
}
int64 nSubsidy = bnUpperBound.getuint64();
//nSubsidy = (nSubsidy / CENT) * CENT;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);
return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}
Um, hm. Versus PPC: int64 GetProofOfWorkReward(unsigned int nBits)
{
CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
CBigNum bnTargetLimit = bnProofOfWorkLimit;
bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());
// ppcoin: subsidy is cut in half every 16x multiply of difficulty
// A reasonably continuous curve is used to avoid shock to market
// (nSubsidyLimit / nSubsidy) ** 4 == bnProofOfWorkLimit / bnTarget
CBigNum bnLowerBound = CENT;
CBigNum bnUpperBound = bnSubsidyLimit;
while (bnLowerBound + CENT <= bnUpperBound)
{
CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
bnUpperBound = bnMidValue;
else
bnLowerBound = bnMidValue;
}
int64 nSubsidy = bnUpperBound.getuint64();
nSubsidy = (nSubsidy / CENT) * CENT;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);
return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
} |
|
|
|
|
Update coming (hopefully) soon, code is done but cudaminer isn't reporting to stdout properly. As soon as this issue is solved with the cudaminer dev 0.04 will be out. A few bugs were also fixed.
|
|
|
|
|
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).
|
|
|
|
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. I have two questions, how many coins will there be? If it's 11 million total for instance then I think this would be ideal. If it's more than it wont ever be as valuable as Bitcoin and so how will you get early adopters to support this?
I asked the same question to SunnyKing about PPcoin. But yes I'm definitely interested in contributing to the project whether with code or in other ways depending on what you decide to do. Right now I'm familiarizing myself with the Bitcoin code but it's fairly straightforward from what I've seen of the Python implementations. ∞ expanding at an extremely low rate 30 years after introduction. You don't want to have no new introduction of coins later on, as you need some method to redistribute wealth even if only slightly. Fees are not really the answer (in my opinion) because of how unpredictable they will likely be. 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. 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. 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. Zerocoin anonymization http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdfWhile 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. 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). I will add you to the potential dev list. |
|
|
|
Hi,
I would really like the idea of new coin that gets rid of constant arm race between miners, because this makes bitcoin really expensive system. It is fundamental problem, because it can make bitcoin non competitive transaction system. Centralized payment solutions benefit from economy of scale, while cost of running bitcoin network is proportional to bitcoin value and transaction volume.
Too bad your paper states that you are rely on exponential increases of hashing speed, which means your system will use as much energy as original bitcoin. Am I right?
I read your paper and it is quite complicated. Do we really need two types of blocks to implement PoS? I'd like to present much simpler mechanism.
Let's copy entire bitcoin algorithm and make one simple change. Instead of using same difficulty target for all miners let's have it dynamicaly reduced by amount of coin days destroyed in coinbase transaction.
Definitions:
base mdifficulty - difficulty calculated using bitcoin alorithm for current block
coin stake - amount of coin months destroyed in coinbase transaction
In bitcoin block is valid when its hash matches base difficulty. In my proposed system block is valid when it matches difficulty adjusted by coin stake.
modified difficulty = base_difficulty / MAX(1, coin_stake)
So for example with base difficulty set as 1000 miner with no stake will have difficulty 1000
Miner with 2 coin months used in coinbase will have difficulty 500.
Of course difficulty adjustment equation can be modified to be less aggresive and/or define maximum difficulty reduction, but you get the idea. Do you see problems with this approach?
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. |
|
|
|
( if this was already mentioned, apologies in advance )
I think the first coin to establish a system that goes some way to avoiding the need for an exchange will likely be very successful. I don't know how/if this could be coded into client wallets etc, but how about this idea :
I want to send $200 to Mr X, in exchange for a number of noXcoin ( or whatever the name of this imaginary new coin is ), I load my own client wallet with $200 ( let's worry about how I can do that in a while ), this creates a string like a bitcoin address, but prefixed with $, this sting is unique and becomes known on the network, using this string, I send the $200 over to mr X.
Mr X has a number if hours, lets say for now it's 2 hours, ( maybe this time period can be set by the initial sender, the 'guy that goes first' ), to send me my noXcoins, as soon as he does so, the trade is 'locked down' by the network and neither party can reverse the trade. If I do not get my coins inside the 2 hours, the trade gets cancelled, and my $200 get credited back to me by the network.
How do I get these $200 into my wallet? I guess that's the difficult part in this at least, I think something has to be built into the design that will allow banks to join the network and offer the ability for people to send $,€,£ etc to their wallets, ( for a small fee I guess to give them the incentive ), right, this wouldn't work from day one, and we have to trust market forces to take place and the banks to jump on board with that one in putting their end of the system in place. Maybe there is another better solution to that ?
There have been a lot of people asking about the addition of decentralized exchanges, and I'll be the first to admit I don't know enough about them right now. The first group (arguably) able to achieve this is opencoin, and maybe a Netcoin specific fork can be given at the introduction of Netcoin. For now, the client will not incorporate any kind of exchange. |
|
|
|
Any solution to the byzantine consensus problem with a hybrid PoW-PoW stake system that further introduces fault-tolerance and enhances network security with no real net increase in computation power should be a better solution, not a worse one (main tradeoff is chain bloat, but I'm sure people find this acceptable). I can understand the need for compromise but where in your paper is this tradeoff made explicit and it's security/efficiency improvement analyzed ? You simply assert that proof of stake is Good, and build from there. The same for the PPC paper, it's all hand-waving spiced with low level implementation details. Don't view it as an attack on you or your objectives, I am a fan of getting rid of wasteful hashing; however this is a very hard computer science problem (Byzantine consensus vs. the Sybil attack) and I expect a hairy analytical paper with all sort of funny symbols and equations, not implementation details. It seems to me the cryptocurrency community needs more thinkers than doers. Not enough analysis goes into these bitcoin forks, and the results up to now are half baked and flaky. Yes, I'm adding more hash algorithms -- but there is no simple way to implement them all together with an ASIC or FPGA without using a massive number of logic units. You're looking at maybe 35k gates with a scrypt ASIC while this would easily require 100k+ to hit all encryption algorithms.
So what ? A modern FPGA can include over ten million gates (virtex 7). A large 22nm ASIC can contain hundreds of millions of simple gates. Indeed it's a bit more work to get the first device done (a fixed cost), but once you have the mask the marginal cost to multiply it is the same as a simple Bitcoin mask which uses a single type of hash. What you should be targeting for is that each chip cannot be much more efficient than a CPU, and scrypt, a password derivation technique, is NOT a proper primitive for this task, the same for you multi-hash scheme. Proof of activity scheme will be added in the newer whitepaper, I'll do my best to give some kind of analysis or at least to attempt to predict likely attacks. It will prevent the double spend problem (as best as I can tell) but may introduce other unique attacks. I'll be frank and say that I'm not well qualified enough to give appropriate theorems in defence of the PoS/PoA system. Something like this will require external audit. Any theorems I could provide after anaylsis will likely have to assume a number of constants anyway, like network hash rate, stake participation, and so on, and relevance to real world security may be dubious. If you incorporate enough different SHA systems, you can easily increase the number of required gates more than 10 fold. The objective is increase in gate size without decreasing CPU or GPU performance. I will be writing the algorithm for this, and I will provide at least some analysis for performance on CPU/GPU and estimated logic gate usage on FPGA/ASIC. Obviously, if you increase the number of gates ten-fold you decrease the number of on-die hash processor units 10-fold. |
|
|
|
Another thing that one may think about for a new coin design is how to be sustainable by avoiding indefinite long-term increase of block chain size:
Fundamentally, as long as a coin uses a pure "block chain" approach, the size can (and will) increase indefinitely as long as the coin exists, and thereby outpace any Moore's law kind of HW growth, which is finally bound by physical limits (size of atoms etc.)... so sooner or later any however big mining node would face problems providing the storage capacity for saving the complete transaction history.
I am wondering whether a concept could be designed to store the current "state" of the currency (state = "which address owns how many coins"), rather than the complete transaction history. The history could still be stored somewhere, optionally, but for sole operation of such a new crypto-currency, the "state" would be sufficient.
Just some rough calculations, using today's BTC as dimensioning basis (21e6*1e8 = 2.1e15 currency base units):
If a mining node wants to store the "state" of the network, how much storage capacity would it need?
--> In the worst case there are 2.1e15 addresses each holding exactly 1 base unit of the currency.
This is about "2100 Tera bits" * (A + B + C), with
A = "nb of bits per address",
B= "number of bits needed to express the balance",
C = "nb of bits needed for some meta data for the protocol and cryptography purposes".
In practice of course, the storage requirement would be a few orders of magnitude lower, so about a Terabyte of storage would probably be enough for all future.
So such a design would require memory well within feasible physical limits, sustainable forever, because a given max. storage limit would never be exceeded.
(Maybe a hybrid "state + incremental blockchain" approach is also possible...)
Light ledger system will be available to the client should they choose to use it. Storage for light ledger will be dramatically reduced (along with end-user security). Some nodes will still need the full block chain. See: https://bitcointalk.org/index.php?topic=169311.0;all |
|
|
|
tacotime: Perhaps a simpler way to utilize multiple hashs is to actually have multiple chains which are 'braided' together. It would work like this, for each time-increment of the network in which we would normally find 1 block, instead one block of each type of hash is found. This forms a set for blocks that are hashed together with simple md5 to created as seed value which servers as input for ALL the blocks of the next time increment. Thus the whole 'braid' advances its individual sub-chains in parallel and in perfect synchronization as only one time-increment can be worked on at a time. It also allows each sub-chain to maintain its own difficulty based solely on the like-hash blocks rather then on an average of them all.
This would address what I see as a potential flaw in your model. Because of the random mix of hash types and the widely different solving times involved it is very likely that a long string of hard hashes will slow the network speed significantly. Conversely a few ASIC friendly hashes in a row result in a huge speed burst. But with each hash having a separate difficulty being continually adjusted to meet the target time you get a more consistent total solving time and at the same time you put a sharp and consistent upper limit on each type of hardware's ability to control the network. You may even tamp down the wild network-speed increases from new hardware too because total network solving time can now only increase at the growth rate of the slowest rising hash-rate.
Now all that sounds great but the really fun part is that the different sub-chains can do DIFFERENT WORK, and have DIFFERENT PROOF methods. This allows the necessary flexibility to solve the old "fox, hen and bag of corn must be taken across river" situation we end up with when we start looking at allowing the user base to decide anything democratically. We know that people have perverse incentives most of the time and will try to make decisions which benefit them at someone else expense. But if they the voting 'right' is distributed differently we can expect different outcomes, thus as people have said Stake-holders are far less likely to desire inflation then are miners. Braided chains allow you flexibility in deciding who get what authority rather then lumping everyone together and requiring each group to validate the whole chain as would be the case with the original one-chain methodology tt describes.
I considered the "braided" model but the problem of network synchronization arises and you'll always be left waiting for the slowest chain. It can be done, but I think it's a little needlessly complex without affording extra security. The random mix of hash types will be addressed in the next white paper, I'm working on a new scrypt variant which will incorporate all hash types into a single block. The only thing left is also modulating the difficulty per block; if I remember right there's almost linear scaling with memory usage above a certain amount of memory, so you can simply scale the difficulty for harder blocks (or, for simplicity, just fix the difficulty). Using multiple redundant chains also adds a lot of network bandwidth, so it's more ideal not to use them (I will present another stake solution soon). |
|
|
|
Even bigger problem is coming. Soon, outdated difficulty adjustment will crash those networks.  Source code is here: https://github.com/aLQ/bitbarIt appears to be a fork of novacoin with tweaked parameters |
|
|
|
Got this error on their site. So is this their DB username/password?  Stack trace: #0 /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:host=loca...', 'zend_admin', '3ErK5wqJ6bTUgxk', Array) #1 /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect() #2 /var/web/bflweb/library/Zend/Db/Adapter/Abstract.php(315): Zend_Db_Adapter_Pdo_Mysql->_connect() #3 /var/web/bflweb/application/Bootstrap.php(203): Zend_Db_Adapter_Abstract->getConnection() #4 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(667): Bootstrap->_initCharsetDB() #5 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(620): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('charsetdb') #6 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(584): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(NULL) in /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Abstract.php on line 144 If yes, can someone tell them to fix their site.... Christ almighty. |
|
|
|
Well, it depends what you define as "verifiability". True, the minimum free energy structure doesn't have a 1:1 correspondence with the actual biological structure, but similar systems have used energy as a decent ranking metric (google Foldit), and it's "the best we've got" as far as a concrete, verifiable calculation. Furthermore, computation of the free energy is far simpler than other possible metrics, whether homology-based (does this look like an evolutionarily related structure), domain-specific (does this have an appropriate # of helices, sheets, turns), etc. Thus, we can make do with free energy as a check for PoW, and I wager that the expansion of computer power for such a project will outweigh the negatives of not relying on other forms of verification.
/technical rant
Yes, I've seen Foldit (I was one of the first bunch of people who used it upon release). That'd be nice, because it'd be really easy for me to doctor without any focus on structure. An accurate free energy calculation is also pretty computationally intensive as compared to a metric like Z-score or RMSD, which can be run in way less than a second. You can reward them based on finding some local minima based on the structure that incorporates Z-score/RMSD as well as free energy, but I could also probably doctor that pretty easily and it actually poorly reflects on overall computational work. In either case, you definitely need someone to verify the solutions afterwards --> centralization of the coin distribution is absolutely necessary (especially as the work needs to come from a central organization!). The easiest thing to do is just to run a backend on the miner's computer that gives them administrative control, even if only on a VM, and then they can tell exactly what code is being executed. The bounty system that I proposed in the other thread allows for these other metrics to be slowly incorporated in the evolution of this coin (i.e. accept structures of protein XYZ only if mean C-alpha distances to reference homology structure is less than 2A.) But that will come in a future version. That's a really, really bad idea [2A confinement for C-alphas] and will result in a lot of not so useful structures. Z-score would be a way better metric for that. This is all based on the assumption as well that you're just looking for a structure closest to what the actual structure achieved through X-ray crystallography would be if you could get it. There are a lot of other important problems, such as dynamic ligand-receptor interactions over a time course. Ideally any PoW system should not be pigeon-holed by a single problem but adaptive to multiple problems. Anyway, seems like a neat idea, not sure how you'll really implement it without administrative control of your nodes, would like to be interested but already have IRL research projects spanning multiple labs (and also here on bitcointalk). |
|
|
|
|
Show Posts
