This should still be easily implementable on the GPU, you just need to test and coordinate what the proper load balancing would be.  Via the TMTO trick, you can reduce memory consumption of the larger memory hashes and subsequently take longer to do them; so, you pipe a large number of these threads along with a small number of threads doing the small memory hashes and you should still get a pretty solid GPU advantage.

With BTC difficulty increasing so rapidly no one knows what the value of LTC should be, before it was pinned nearly equal to BTC and it's been progressively increasing in relative value GPU mining.  2nd gen ASICs that are soon coming out are 100+ fold the power efficiency of GPUs; we might expect that with the rising BTC difficulty, that LTC price may dramatically increase to keep it in line with the cost to produce in terms of electricity.  But this is all up to the speculators who play the market.

There is already a fast implementation of the Lucas–Lehmer primality test on AMD cards, I'd guess one for the Fermat primality test would be a matter of time.

http://mersenneforum.org/showthread.php?t=12576&page=176

Mfakto implements sieving as well: http://www.mersennewiki.org/index.php/Mfakto

They're both for October Delivery

Yeah, I haven't been keeping up.  Is everything still shipping on time?

Also, I placed an order for a starter and then a couple weeks later for a ton of H-boards, any way I can get them all shipped together without the extra delay?

Sorry this took so long, I was moving across the country and separating stuff between my ex and I

Lottery winner hash enables someone with a matching ticket to claim 25 coins (as per wiki; this will be in next version of whitepaper).  There is an average of 125 coins generated per block from stake votes.

1 in 65536.

Tickets sold via the kickstarter are just at predetermined prices to ensure the funding of the project and have nothing to do with what their eventual value might be (which could be $0.0001 USD or $100 USD).

There is no cutoff for the donation amounts, however we will run out of ticket.

Unfortunately ingsoc has indicated that there are a number of legal things to get around now because this is technically being considered an investment in a number of jurisdictions.  Until this is ironed out and we have a country willing to host the funding, this is a little up in the air, but it should be soon.

Depends on the question above -- we're sorting out the legalities.

30-60 days, but it's likely all the tickets will be sold within a week or two given the current interest.

This was adjusted to ~45 days.  Ticket generation occurs on a per block basis, so it's ~45 days worth of blocks after the ticket was submitted to the blockchain (and so the first ones will mature ~45 days after the genesis block).

See the wiki:
http://www.netcoin.io/wiki/Netcoin_Proof-of-Work_and_Proof-of-Stake_Hybrid_Design
http://www.netcoin.io/wiki/Algorithms_for_PoS_Voters_to_Assess_the_Validity_of_PoW_Blocks
Basically, PoW miner submits block to network, PoS miner checks to see if it also saw the same Tx, then validates with a PoS subblock.  The PoS subblock is where the PoS miner's coins are generated.

The private keys will be shipped to you via PGP.  After that you just feed them to the client who can import them in an automated fashion, and set the client to automatically mine PoS blocks.

Block voting will be automated and extensively tested, but of course you can manually vote on blocks too if you want (or just set the client to accept any blocks seen on the network).
http://www.netcoin.io/wiki/Algorithms_for_PoS_Voters_to_Assess_the_Validity_of_PoW_Blocks
Basically the only work you have to do is leave your client running with the private keys.  The block voting just ensures a consensus network of transactions, so PoW miners can no longer ignore or cherry pick transactions -- if you submit a transaction to the network and the fee is high enough, it can NOT be ignored by the PoW miner, at least with the proposed automated PoS voting (unlike Bitcoin, where the PoW miners can do whatever they want to the transaction tree).

Maybe I forgot to indicate it in the wiki -- stakeholders voting Yea on a block with majority Nay votes have their rewards destroyed, so voters have an incentive to vote with the majority.  You can always vote in all PoW blocks if you like, though, so long as you don't worry about having your rewards destroyed if you aren't voting in the majority.

Signatories = tickets.  You need a majority of tickets signing to pass the block -- if only 2/5 votes, the PoW miners will continue hashing old work to get a new PoW block with a new lottery winner number.
If 3 out of 5 sign it, the block is included in the blockchain as either valid (Yea) or invalid (Nay), and the ticketholders for these 3 tickets get their reward.  PoW continues from this new block.
PoW doesn't have to wait around for 5 people to sign it, but the block header includes a hash of the ordered subblock headers of the previous voters.  So, if 3/5 sign and the PoW miners generate a new block from only these 3 votes but the PoS miners see 5/5 signatures, the PoS miners will probably reject this block that only includes the 5 votes.  Network propagation is pretty fast (~seconds), so as long as the PoW miners give themselves a few seconds they shouldn't need to worry extensively about stales from voting.  This does introduce a type of attack where someone tries to mess with the network by submitting PoS votes late and forcing PoW invalidation via PoS, which will need to be addressed at later steps (probably a similar solution to transaction time evaluation as described in the wiki can be used).  Whether or not anyone would actually want to perform this attack (and potentially forfeit PoS coins) is arguable as well, but there does need to be a safeguard against it.

"For the first ~45 days of the coin (32,768 blocks), there will be no lottery hash winners chosen. To safeguard the network, stakeholder tickets for these blocks will be issued via the crowdfunding platform, in proportion to the quantity pledged."

First sentence says there will be no lottery hash winners "chosen". Chosen by whom/what - yes I read they will be 'randomly selected', is this randomness the same mentioned in the whitepaper? Then second sentence says to safeguard the network tickets will be issued from crowdfunding... so how exactly does crowdfunding secure the network when he with the most $ gets the most votes? Also if the first 45 days of blocks will be exclusively allocated to crowdfunding pre-assigned ticket holders, how exactly does this incentivise any mining?[/quote]
For the first 45 days I haven't exactly decided how to select ticket winners.  We will have the unusual event in which we have exactly 5 tickets available per block (there will be a lot of variance on the actual chain after 45 days) and that we have 5 tickets for any possible lottery winner hash.  For the chain to keep going, then, we need to select each lottery winner hash ONCE AND ONLY ONCE for any given block.  You can use the current selection method as stated before with a rollover if you hit any lottery winner number that's already been selected before, ensuring that we hit every lottery winner hash once.  There needs to be a way to deal with absentee voters at this stage as well.  The algorithm as described in the wiki already does, but if we're selecting each ticket once that means eventually we'll come back to those same tickets and at some point the holders will need to vote to keep the chain going -- I guess we can do some kind of checkpointing for the first 45 or so days that is only active when we have a case of PoS tickets never being claimed, just to ensure the chain runs smoothly until we begin to accumulate more PoS tickets via generation.

Furries

Sorry I've been gone. I didn't even have a desk to sit at until today, I'll reply to the questions above tomorrow.

He's busy throwing Casascius bitcoins at strippers

(I'm sure we'll hear from him soon)

I will answer these questions in a bit, I'm really pressed for time atm

Batch No 8 is too old?

Same problem.    I will keep clicking it I guess

edit: Got through after about 30 clicks.  Now I have 15 minutes, which isn't enough time to get to my offsite wallet.  Sigh.  I'll have to do this in a bit.

I'm trying to pay with BTC and it's giving me an error connecting to the payment provider.

After tweaking to lottery winner/ticket system, there was no need to use 2^16 as the number of blocks to calculate the lottery winners with. Ticket maturity was then altered to 2^15 blocks (45 days), as 2^n was useful for the formula I'd been using to calculate crowdfunding distributions.

It's older than Feathercoin and almost all of the new features are unique...  Since publishing various ideas a few have been incorporated into other blockchains, e.g. my memcoin proposal was integrated into YACoin and my random hashing scheme was into quarkcoin, but I'm not really going to directly take credit for any of that.

Ingsoc felt like the formula I was using before was a little too penalizing to latecomers, so I tweaked it a bit.

You would need a BPP-type formula for the golden ratio -- I don't believe one yet exists.

http://crd-legacy.lbl.gov/~dhbailey/dhbpapers/bbp-formulas.pdf

The following sections have been updated:
http://www.netcoin.io/wiki/Distribution_Scheme_for_Crowdfunding
http://www.netcoin.io/wiki/Netcoin_Proof-of-Stake_Voting_for_Proof-of-Work_Blocks

The following sections have had their initial commits:
http://www.netcoin.io/wiki/Algorithms_for_PoS_Voters_to_Assess_the_Validity_of_PoW_Blocks
http://www.netcoin.io/wiki/Netcoin_Adjustments_to_the_Proof-of-Work_Transaction_Tree
http://www.netcoin.io/wiki/Addressing_the_%22Bitcoins_and_Red_Balloons%22_Issue

It looks like the "Red Balloons" issue is largely mitigated by the PoS mechanism Netcoin uses, but I adjusted the way fees are dispensed as well to further address this.

Now that this seems squared away, I can finally get back to tearing apart the old version of the whitepaper.  The new one should be shorter and more to the point, with the wiki reinforcing the concepts.

Forum will be back online when next ed. of whitepaper is released.

This introduces another vulnerability.  As these bits come from further in the past, the majority of the numbers used by the ticket are known well in advance.  The problem with this is that a person can seek to acquire all tickets with these knowns bits and effectively halt the chain if they get 64 * 3 = 192 tickets in advance, probably by collaboration with someone.  So, someone with only 0.05859375% of the total network tickets (at ideal concentrations of tickets) can now halt the chain.

The solution is to just use bits from the most recent blocks instead of those far in the past.  Creating a chain of length 8 containing all the bits you want to select for certain tickets is likely quite a computational ordeal.  Conversely, you would need to procure all these tickets within this timeframe if you didn't want to manipulate the PoW chain, also very unlikely.

Thanks,


We will be capping contributions to $10k per individual or company to prevent severe centralization, as it'd be bad to have the majority of stakeholder tickets in the hands of any single individual (not that anyone is likely to destroy the chain in the first 90 days anyway, as it doesn't make a lot of sense monetarily for the contributor).