@Impaler Now I remember why we need bits from the current block; see the latest wiki update for more details, but I'll x-post a note from it here: NOTE: It may not be immediately clear why we use 6-bits from the most recent block. Consider the attack in which a malevolent stakeholder has the majority of tickets for any given block header hash. If we use only old blocks, especially ones far back in the history of the blockchain, no matter how many new proof of work blocks are generated the attacker can still halt the chain. Now consider the instance in which 6 bits are taken from the most recent block; we have 2^6 = 64 possibilities for the lottery winner. The malicious stakeholder in this case can block only one of 64 possible blocks from entering the blockchain; in the event this block is not voted on by the malicious stakeholder, PoW miners can continue work from the previous block and generate another block with a different lottery winner. Then, non-malicious stakeholders can push this block through the network and the chain can continue. It is extremely important that PoW miners continue on old work until the latest block has been verified by a majority of stakeholders for this reason. This also gives an interesting trade-off for security: we can choose up to 16 bits from the current block, however, the more bits we choose from the current block, the more readily a PoW miner can manipulate the lottery winner. Using blocks that are weeks or months old mitigates this manipulation, however, without choosing several bits from the current block we enter the case where an attack as detailed is extremely likely. So, we must select n bits from the current block at a level that allows for some options in terms of lottery hash, but which does not allow for the complete manipulation of the lottery winner. In the case of 6 bits (64 possible lottery winners), the PoW attacker mining at the current block can only generate (64 / 65536) * 100% = 0.01% of possible tickets. |
|
|
|
|
Thanks for the shoutout. Netcoin has adjusted PoW slightly (to make it easier to implement and get it out faster); this will be in the forthcoming version of the whitepaper, and the general algorithm is on the wiki.
|
|
|
|
Problem is that 62% is the rate it will increase for a few months, likely until November, then it will decline. I would guess the curve would likely be like with GPU mining when it first started out, since GPUs had a very long life within the bitcoin network. Or maybe FPGAs, although they seemed to have a fairly short life with respect to their mass introduction and subsequent becoming "dated".
The amusing thing is that people keep shouting out, "It'll never make ROI," based on the assumption that the hashrate can continue its exponential increase in computational power at several fold the rate of Moore's law (never mind anything else) and that the price of Bitcoin will always stay the same. Personally I would be surprised if we see KnC miner products before 2014, though. |
|
|
|
If solar designer comes up with his proposed scrypt fork we can talk about that then,
Details? I am going to continue posting about possible incompatible changes to
scrypt (thus, deviating from scrypt) to crypt-dev only. I made this
posting to the scrypt list as well because the numbers above are for
scrypt proper (a modified implementation of it producing same results,
as verified against test vectors).
This is nothing new/unexpected, but I thought some of you could find
this useful to get a better feeling of how the scrypt TMTO behaves. http://www.openwall.com/lists/crypt-dev/2013/03/21/1He later made a TMTO defeater and then defeated it himself using a thread desynchronization trick, you can read about it on crypt-dev. In any case, he still actively posts about sCrypt related posts in crypt-dev, I wouldn't be surprised if the problem wasn't still in the back of his head today. |
|
|
|
An update has been given on the PoW hash function and it has been dramatically simplified; it now uses the digits of pi to random algorithm selection. N is fixed because I'm worried about it potentially introducing vulnerabilities into the chain if you play with it a lot, and I'm not sure if offers much more security even if you do. http://www.netcoin.io/wiki/Netcoin_Proof-of-Work_Hashing_FunctionNonetheless, an easy PoW function will let us put the chain out faster, which will let enable us to much more easily avoid the whole super fast ASIC fiasco. If solar designer comes up with his proposed scrypt fork we can talk about that then, but right now it doesn't exist and Netcoin needs to move forward. There's only a couple topics left to edit on the wiki (that I'm still meditating on), then we shall move to launching the crowdfunding. Some answers to commonly asked questions: 1) The distribution of funds was designed to get at least $50,000 by crowdfunding ASAP, which I think should be the absolute minimum we use to launch the development with. $100,000 is ideal, though. There is a mathematical function governing it (that should be obvious) and you can manipulate that to cause variable price differences among the tiers. I have sent this data to _ingsoc for him to look at and see what he thinks. 2) I want to deal with fiat so that we don't have a totally irresponsible BFL preorder-ish fiasco where the product doesn't come out forever and the investors make nothing back. If one crowdfunder is better for global persons eg indiegogo vs kickstarter, we will go with the one that is more accessible. 3) I will add some more notes on how you will get NTC with your stake tickets soon, and how the keys will be distributed (likely PGP or snail mail). I can't address things directly right now like web API, etc due to time constraints, but if you think it is a good idea, please add it to the wiki! I am just going to concentrate on this so we can get the ball rolling with the basic development. Obviously things like equivalents of BitPay or CoinBase (especially coinbase) are critical to the support and adoption of the currency, but that's beyond me right now. |
|
|
|
I bought 5! Sign me up for another 5 at 0.1 BTC!  |
|
|
|
While we are waiting for the dev team to work on the technological aspects, do you feel that its worthwhile to have a website content/marketing/strategic planning team established early on so that when the coin is released, we would have a plan as to how to strategically market and increase the adoption of this coin?
This is all an important part of the cryptocurrency's design, but beyond what I can supply right now in terms of time. _ingsoc has largely been handling this aspect up until now. |
|
|
|
I think you are doing a great job, the kickstarter scheme is just brilliant.
This is the first coin that I know of that fully uses the potential of PoS from the start.
BTW, a link to the wiki in the first post would be very useful. It is getting harder and harder to find things in this thread, and just FYI the netcoin forums are down ATM.
Thanks! I added the wiki to the main page. The forum will be back up around when the kickstarter launches (and I can get my hands out of this and leave it to the people implementing it to move forward with the project, so hopefully we will see less delays). |
|
|
|
For the first $50,000, there will be 1,956,000 coins offered through stake votes;
$50,000 / 1956000 coins = $ 0.02556237218813905930470347648262 per coin
Not only is that wiki page written atrociously, you should not be drawing any conclusion that the kickstarter has anything to do with the value of the coin. What the hell Thanks Etlase2 The kickstarter has nothing to do with the value of the coin -- but it is used to disseminate stake votes among the network before there is any maturation of the stake lottery winner system, and to provide funding for development. The rest of the wiki is here (although some information is still being worked out): http://www.netcoin.io/wiki/Netcoin:Community_Portal |
|
|
|
So are those rates firm? Also is there any way to pay in Bitcoin or Litecoin?
I updated it again, I realized it should have been 65536 blocks, or 327,680 stake votes (whew, sleepy). But that means they're even cheaper, I suppose. And, no, not yet, well give everyone a heads up as to when the kickstarter for the chain will launch and when we have a dev team in place. |
|
|
|
|
1) Yes
2) The PoS votes for the first 20,864 will be predetermined, yes, but the PoW rewards (which are greater than the PoS rewards) are given to the miners. This is partially because no PoS submissions will mature before 20,864 blocks.
3) The probability is that all tickets will come up within 65,336 blocks, but the initial lottery ticket hashes will be selected randomly for the first 20,864 blocks within a range of 0-20864 to ensure that all PoS miners contributing to the kickstarter will get them. This may later be adjusted to 65,336 blocks, I haven't decided yet and am still thinking about it.
4) 39,123 coins, well, it will be truncated so 1564 tickets I guess.
I may adjust this to 65,336 blocks in the coming days, check back. But this should give you guys a general idea of how the distribution works.
|
|
|
|
Hmm....just to confirm, so around 2.6 million coins will be issued via the kickstarter?
With a goal of $100,000, this makes it effectively it $26 a coin?
For the first $50,000, there will be 1,956,000 coins offered through stake votes; $50,000 / 1956000 coins = $ 0.02556237218813905930470347648262 per coin |
|
|
|
Ah I see your plan is a bit different then what was presented in the first paper and which I was still operating under. Your looking much much deeper into the block-chain and picking individual bits out to create a 1024 bit value that gets hashed before modulus. While this dose pull in a lot of good entropy I'm still concerned that having Block #0 (the block immediately preceding the one being mined) is a concern. If your willing to go thousands of blocks back for entropy why not just start at block #64 (that's 64 blocks prior, and go back all the way back to #65599) to completely block any possibility of manipulation by throwing away certain solutions. An ASIC equipped attacker would need to mine astronomically large amounts of blocks (8^64) in order to have control of even 1 bit of the resulting lottery value. It's overkill, but better to be safe then sorry. Well, I didn't want the tickets/lottery hashes to be completely known before they were able to be used (especially the lottery winner hashes). To manipulate the ticket/lottery winner hash if you made the final bit from a block 64 blocks behind, you would only have to manipulate that block from 64 blocks ago. In any case, manipulation of that block only allows you to select from 2 potential ticket/lottery numbers. To completely manipulate ticket generation, you would have to manipulate the 16 last blocks in the chain. I think it's likely that I should do away with the pulling of bits and then hashing completely and simply pull 15 bits from the last 65535 blocks and 1 bit from the current one (and something similar for ticket generation) and make that the ticket. In order to pull off such an attack, the attacker would need to have 51% hash power during each of these 16 blocks, which is extremely unlikely given the timespan over which they occur. Your concern for a set rotation of hashes causing the lottery ticket value to be drawn from blocks with similar hash type blocks can be solved quite simply by going back in a jump size that's not a multiple with your number of hash types, say ever 101 blocks which over the 1024 blocks your sampling should draw equally from all hash types. I think it's easier if you choose a different entropy source; I'm going to update the wiki later today with a more recent (and interesting) idea. |
|
|
|
I haven't looked into much detail but, isn't quarkcoin using the random hashing algo that netcoin details ? This could provide a nice test bed for quarkcoin ... or ... tacotime is it you ?  Quarkcoin seems to have the same idea, although it looks like they are avoiding usage of scrypt. |
|
|
|
Wow, this coin will either never be released, or by the time it is, there will be much better. Taking way too much time.
I'm working all day today (took the day off work) on finishing the wiki specifications and moving back to the whitepaper (_ingsoc wants it done by Monday for some potential developers), so, probably it will be moving to development pretty soon. When you make sweeping changes to the Bitcoin protocol, there's quite a lot that can go wrong. I identify new vulnerabilities (and potential solutions) every time I sit down to work, I feel like. |
|
|
|
|
It's kind of funny hearing everyone talk about ORSoC like they're some kind of master chip designing company... They're listed on LinkedIn as having between 11 and 50 employees. Butterfly Labs, comparably, has about 40 employees.
|
|
|
|
Does this mean the 400GH/s kit can made to easily go up to 640GH/s? What's required to do this? Changing some resistors and crystals?
They will do about 614 GH/s. Please see: At 0.8 V and clock of 54, these chips get 2.4 GH/s each. 16 H boards x 16 chips per H board x 2.4 GH/s per chip = 614.4 GH/s. These are not the same boards. No, but Dave has stated in this thread that the H board's voltage reg maxes out at 0.8 V, which is the apparent stock voltage. So, all one needs to do is adjust the clock. edit: Apparently H board v reg maxes out at 30 A and stock voltage is 0.65 V, so you will need to modify the resistor to get voltage up beyond that This post seems to specify that achieving this performance on an H board will be difficult without extensive modification to replace both the resistor and the v reg cscape, a few of us are wondering how much the h-card can be overclocked to. Have you tested that? We know that it is limited to the regulator.
30A reg maxout is on the board. 40A max at core limit. There is no reg subtitute with higer limits (as I know, I already tried to find). To maximaze the chips hashrate we might need board with less chips. dave and cscape qutoes; For 0.65V you need exactly 1K resistor for R01F. For 0.70V you need 1.5K. With 1K resistor I get 1.26Amps @ 12.0 V, so 15Watts for an h-board. [edit] Remember, with 16 chips, soldering that higher value resistor will quickly max out the amps that the regulator can handle. The 2.7GH/sec result I got with a single ASIC test board required 2.5A, and 0.835V. If you were to attempt that on the whole board, the total current of 40A would exceed the capabilities of the regulator. -------- btw great work cscape, awesome! Picture is kind of look but can not touch  Come on investors, grab this oportunity! |
|
|
|
Does this mean the 400GH/s kit can made to easily go up to 640GH/s? What's required to do this? Changing some resistors and crystals?
They will do about 614 GH/s. Please see: https://bitcentury.io/blog/initial-testing-of-bitfury-asicAt 0.8 V and clock of 54, these chips get 2.4 GH/s each. 16 H boards x 16 chips per H board x 2.4 GH/s per chip = 614.4 GH/s. Note that this is 614.4 GH/s at stock voltage. The H boards as sold here appear to be 0.8 v running at a clock of 48 for 1.5 GH/s per chip, or 24 GH/s per H board. So the 50% increase in hash power should be easily achievable. |
|
|
|
|
No offers...? Let's get this going, 12 BTC offered.
|
|
|
|
|
Show Posts
