|
guiminer is just a frontend; you probably need to update the cgminer version that comes with guiminer
|
|
|
|
P.S. He said that it was "not exactly a pool". Not sure what does it mean.
I'm not sure either. That username and password has been used for nothing except pools for me, so I have no idea from where else it would have been obtained, especially by SQL injection. |
|
|
|
|
Coinotron has confirmed it wasn't their pool. Here are the other pools with which I was registered:
pool-x.eu
litecoinpool.org
Burnside's pool (ltc.kattare.com)
give-me-ltc.com
NuKingsMiningCo
|
|
|
|
|
Okay, thanks for the information.
|
|
|
|
I had about 10 LTC stolen.  edit: Hot wallet address is okay, so no compromises there. Looks like it was just taken from my ltcmine account. |
|
|
|
Yes, an x1024 memory might be constructed with (32) blocks configured for x32 width. Is there something you didn't understand about that? (this is just repeating what I said earlier?)
No, that makes sense, before I was confused because I thought you were implying that a 9 KB memory block could have a 1024-bit width. |
|
|
|
The total RAM per block is 18KB. Each block has a 72-bit width. I don't really know where you're pulling your numbers from. Even if you calculate in parallel, 128/18 = 8 block RAM units required, with 72-bit widths each --> not 1024 bit width either.
I think you are misinformed about what is and is not possible. You can construct whatever width you like by putting multiple units in parallel. This is commonly done, and is a general feature of FPGA's not unique to Xilinx. The vendors put them into small blocks like that to improve the granularity / flexibility for the designer. As a result, you effectively lose capacity (bits) when your chosen configuration doesn't map efficiently to the underlying memory organization. Artix-7 is even better, but limiting the discussion to Spartan 6 which many people have already bought, here is some documentation: See page two of this: (a) http://www.xilinx.com/support/documentation/ip_documentation/blk_mem_gen_ds512.pdfSee page nine of this: (b) http://www.xilinx.com/support/documentation/user_guides/ug383.pdfSee page two of this: (c) http://www.xilinx.com/support/documentation/data_sheets/ds160.pdfTo get a x1024 memory using (a), you can see from (b) that one possibility might be (32) instances of (x32) width. As far as the capability of the LX150 part commonly used on existing bitcoin mining boards, you will see in (c) that this devices has a total of (268) such blocks. So accommodating the 128KB scratchpad in SCRYPT could be done with (64) blocks configured for (x32) width and (32) units in parallel. The LX150 could possibly hold (4) such memories, but I think you run out of gates for SCRYPT arithmetic well before that. I'm sorry, but I still don't follow. (b) Table 4 that you cited shows a maximum width of 32-bits for a 9 KB block. With 18 KB data blocks, the maximum width is 64-bits (plus error checks bits). You can get get a 32-bit writes in parallel on 32 separate 9 KB blocks, which is sort of like a 1024-bit interface (I guess; 1024-bit interface really implies that you're writing 1024-bits a cycle through the same memory interface...). I think a direct implementation like this won't achieve a very good speed, though (less than 10 KH/s on most of these chips). The better implementation would just run in the allocated memory and remake the LUT as needed I would think. See the kernel for cgminer and reaper, and use of the "lookup gap" function, which more or less does this. |
|
|
|
|
You guys [CAVirtex and you] are worse than the Canadian banks. I'll switch from CAVirtex when you offer 1.5% or less.
|
|
|
|
|
Okay, thank you for your answer.
|
|
|
|
There's still about 30-40 GH/s of miners left to migrate to Litecoin from bitcoin.
How did you get the 30-40 GH/s number? The BTC network was about 20 TH/s before the introduction of ASICs... but with the introduction of ASICs a disproportionate amount of new hash power came online as the price of BTC went through the roof. http://bitcoin.sipa.be/On the low end, there is 10 GH/s left to migrate, on the high end 30-40 GH/s I would say. Additionally, much of the new LTC network is from new miners, not old ones. I've known people setting up operations in the hundreds of MH/s. |
|
|
|
All systems ignores the number of blocks. The both PoW and PoS systems calculates "trust score" for each block.
In BTC-like systems, for example, this "trust score" comes from nBits field. You can't overwrite current chain with your own, if you have not enough "trust score" aka bnChainWork. Even if you generated 100x longer chain. I see, thank you for taking the time to answer my questions. How do exchanges implement confirmation, then? As you worked with BTC-e with NovaCoin, you must know. |
|
|
|
^^ Thanks for the criticism. Here's your enlightening weekly update: v0.3.0 has been released. Upgrade should be performed before protocol switch on March 20th. A block chain re-download is necessary for the upgrade. See the 0.3 release thread for detailed instruction: https://bitcointalk.org/index.php?topic=144964.0v0.3 protocol involves several changes, first the proof-of-stake hash modifier is switched to one computed from roughly 9 days worth of blocks. The blocks are grouped and 64 blocks are selected based on a 'selection hash'. Then each selected block contributes one bit to the modifier. The purpose of stake modifier is to prevent stake owner from manipulating future stake generation at the time the coin is confirmed into block chain.Two other protocol changes are made: stake hash weight now starts from 0 at 30-day minimum age requirement; coinstake timestamp now must match block timestamp. : The protocol upgrade in 0.3.0 includes a new algorithm to derive proof-of-stake hash modifier, the entity that scrambles computation for stake owners, which replaces the current proof-of-stake difficulty used as modifier in 0.2 protocol. The design was started late September last year, when I first began to realize the issues with using difficulty as modifier. Honorary mention also goes to Jutarul, who independently discovered and verified an issue with using difficulty as modifier and published on bitcointalk in December last year, while successfully executed a demo attack on the block chain. Other changes in the protocol include starting hash weight from 0 at the 30-day mininum age, and requirement that coinstake timestamp must equal block timestamp. Overall 0.3 protocol should significantly strengthen the proof-of-stake protection and resolve the current known vulnerabilities. https://bitcointalk.org/index.php?topic=144964.0Here is your enlightening answer as to what these 400 lines of code accomplish in kernel.cpp: Thanks. Surely you have already touched upon the reasons of what you refer to as 'opaque' development, mostly, due to lack of resources, secondly, for security concerns. I only have time to discuss the design with trusted peers before release. I hope you can understand that there is lot of work involved and it's not trivial work to even understand the design and its intricacies. There is no separate document, I have put some comments into the source code, it's not long at all, only about 400 lines in kernel.cpp and some of it is preexisting code in v0.2. Interested parties can take time to look at it, and discuss it maybe in my disclosure thread. I'll try to answer some of the questions along the way. edit: Diff for anyone interested, took me a while to dig up https://github.com/ppcoin/ppcoin/commit/b0b7eb2ecad409a2a98f6aa35bf99a4fb247ff35 |
|
|
|
|
Right. But, you need 6 blocks to double spend (unless there's some kind of "block trust score" system that ignores the number of blocks and just calculates how much to trust each stake block).
|
|
|
|
There is no difference between "1 wallet" and "500 wallets" configurations.
So the number of stake blocks that would be generated after bringing them online after a 90 day period is the same? |
|
|
|
stake is only generated up to 90 days so it cannot be super charged for an attack, also new 3.0 protocol has protection against finding pos block one by one.
checkpointing is still there, but just in case of som unknown vulnerabilities. users trust developer so there is actualy not mush pressure from PPC supporters to remove it.
there are no known possible atacks that would be easier on PPC than on any other coin including BTC. The new protocol (as far as I can tell) just makes it harder to spam consecutive blocks from a single source (again, it's hard to tell because SK doesn't want to explain it in simple pseudocode) -- but I think you can still do it if you keep multiple wallets. For instance, if you have 500 clients all with some coins 90 days old, and you keep them offline then suddenly bring them online, you might be able too. |
|
|
|
Current difficulty: 364
Sigh.. it seems this last wave of Bitcoin mania brought a lot of new GPU miners to Litecoin.
It petty much killed profitability of it... hope you guys weren't planning on breaking even anytime soon.
It's good for the strength of the network, but sucks for miners looking to pay off or buy new equipment.
Price will be at $5-10 in a month if this keeps up, I would keep your chin up. There's still about 30-40 GH/s of miners left to migrate to Litecoin from bitcoin. If anything, now is a good time to buy. |
|
|
|
|
...both for $500? or each?
|
|
|
|
|
Show Posts
