|
Update for 0.04 written, I will test it tomorrow and then probably release it tomorrow night
Then I can finally get back to MC2
(Also oh God my source code is ugly for guiminer-scrypt haha)
|
|
|
|
|
Yes, it would be a good idea to include the block height and also the depth in the block in which the last tx appears.
|
|
|
|
I had been thinking about similar idea independently and this is what I came up with:
Blockchain has two different functions.
1 ) Maintaining a distributed database
2 ) A way to know which view of this database is correct/most up to date
These two functions are independent. Distributed database can be almost anything you like as long as you define some basic rules for applying modification to it.
1) works this way:
There is some initial database state (genesis block). Every subsequent block contains some operations that modifies this state (in bitcoin these are transactions).
2) works as follows:
Block headers contains proof of work which is used to check which database view should be considered correct. Rule is simple: you find peer which have longest block header chain (in terms of proof of work) and you know what the correct database should look like (best block header contains hash of correct database). Then you download current database from peers and check whether it is correct.
Bitcoin uses somewhat peculiar database format: list of all transaction that happened from genesis block (block chain still needs to be stored at some nodes for the sake of history, but not all). I don't see any reason why database format can't be changed to something else. For example list of public keys with corresponding balances as you propose.
Here is my idea:
Database is just a list of accounts.
Every account consists of three things:
(public key, balance, block number of last spend operation)
Every block includes some number of transactions.
Transaction is (from_pubkey, from_last_spend_block, amount, destination_pub_key). You prove your ownership by signing it with private key of sending address.
Miners collects transactions, apply it to current database state and generates block.
In block header miner include hash of transactions and hash of database after applying all of these transactions.
Network validates that all included transaction are correct just like with bitcoin.
What is better than bitcoin is that block contents are not really needed after network reached consensus about database state, so after say 1000 blocks you can discard oldest block contents and just store account list at that moment.
This post is probably little chaotic but I can clarify my idea if you give questions.
Ideally the client should keep a ledger of addresses and amounts at the address to prevent double spending. Then, miners could hash this ledger with modified transactions and include it in the block header so that all clients can verify that their ledger is the same. You can use a consensus network via stake to do ledger verification, too. I will be trying to integrate this into MC2/Netcoin, and hopefully bring the client load into the mb range, but I'm going to give no guarantees at this early point in time. |
|
|
|
|
This week, code is about half done
|
|
|
|
Implementing native stratum should be really low on the priority list. There are stratum proxies anyone can use to connect to any pool that relies on stratum. Please focus on the stuff that really makes this miner unique (CUDA/CPU code optimizations)!  I'm adding cudaminer to guiminer-scrypt right now, the stratum proxy is already there so you don't need to worry about it for now. |
|
|
|
|
Reseat the GPU and the extender or try swapping the cards around
|
|
|
|
Re-read my post again, I have named only one person, a single entity, and the "others" refers to the other altcoin creators if you couldn't comprehend it. It is you who can't read. Pooler is in fact a very good friend of mine, he has put a lot of work into Litecoin.
Since you're such good friends with pooler, who is helping coblee write the 0.8.1 update, why don't you ask him? |
|
|
|
Just saying, there are like around 10 commits in the past year and this guy hasn't even pulled the recent Bitcoin changes into Litecoin, as the code is similar. In fact, the Terracoin dev was waay more productive than this guy. I guess he(coblee) is looking to disappear like Satoshi, so he doesn't plan to update the UI, add more features, optimization, nothing?? And just for reference, have a look see at the only change in the last 2 months https://github.com/litecoin-project/litecoin/commit/3aaa7ba5d05ff7ec35e2cd704e1e1b3da58b70b4Way to cite a commit that coblee replied to within the last 24 hours. If you want to discuss litecoin dev, come to #litecoin-dev on freenode. Coblee, pooler, and the rest of the gang are all there. http://webchat.freenode.net/ |
|
|
|
|
For LTC or BTC.
Require the following:
Domain name registration
Setup of simple machines forum similar to bitcointalk.org
Setup of Mibbit on-browser chat client using the WebIRC protocol (user IP/domains hidden by server)
Give me a quote
|
|
|
|
What are the benefits of Proof of Activity vs Proof of Stake? Why not do a hybrid of all 3 to get the best of all 3?
In short, no chain bloat from tons of PoS blocks and more secure. Blocks come regularly as opposed to sporadically as per PPC. Forums and chat coming soon. |
|
|
|
When will the litecoin client be updated?
Around june, coblee wants to see if the may update for bitcoin breaks anything yet. |
|
|
|
|
Just to let everyone know, it's not dead and I'm still working on the theory. It's taking me a while to develop the new proof of stake/proof of stake hybrid system, but I want to be confident that it can provide 4 minute secure confirmations to try to make it the fastest cryptocurrency available, without having to compromise security. And that's honestly a hard task, but I think I might be onto something using a new system of secure block signing with stakeholders. So, stay tuned. It will not be anything like the PoW/PoS system that PPC uses and will not borrow code from that, but more similar to cunicula's proposed "Proof of Activity" system but faster and more efficient.
|
|
|
|
|
My 7970s at 901 MHz core / 1512 MHz RAM / 937 mV core pull about 170w AC (140w DC) per card while getting 630 KH/s. This is without touching the power limiter. I seriously doubt Malta will have a problem mining litecoins. The 2x 8-pins themselves can give enough power to run the card at low clocks/volts, let alone the PCI-e slot. The reference 7970 I have, by the way, runs at <60C load next a bunch of 6950s that run at 85C load. Tahiti is insanely energy efficient when it comes to scrypt.
|
|
|
|
I think the pool is still solving blocks, as there is about 1.5 MH/s unaccounted for right now: https://www.litecoinpool.org/poolsWe'll probably get payouts when Balthazar wakes up and realizes the frontend is broken. It also looks like the backend might be under DDoS as share submission appears to be slow. |
|
|
|
|
Groestl's 256-bit implementation is vulnerable to collision attacks -- I think you end up with 2^64 possible hashes in the worst case. If I remember right a lot of the AES-function utilizing secure hash functions suffer from this problem.
|
|
|
|
Dumb Question... as of 04-25-13 Is the latest version of this on the original first posting?
Yes New version coming soon, I'm done my exams but am very sick so not as much work on this or MC2 has gotten done. Sorry guys |
|
|
|
|
0 MH/s here, but shares still being accepted, hmm.
|
|
|
|
|
Show Posts
