This concept creates a "random lottery" to decide who creates the next block that is not biased due to *stake* and does not require the energy inefficiency that PoW has.
The only real issue is "account" creation and I think that can be solved by the creation of a "community driven" project (where accounts would have to be "earned" by performing "real work").
|
|
|
I have been playing around with a new idea for "proof" that might be suitable for a new kind of blockchain.
Blocks would be created by accounts whose hash matches closest to "hash chain" hashes published in previous blocks (yes - controlling the number of accounts that can be created is a key issue but one I have already considered).
For those not familiar with what a "hash chain" is let me quickly illustrate (using MD5):
MD5( "test" ) = 098f6bcd4621d373cade4e832627b4f6 MD5( "098f6bcd4621d373cade4e832627b4f6" ) = fb469d7ef430b0baf0cab6c436e70375 MD5( "fb469d7ef430b0baf0cab6c436e70375" ) = 25ab3b38f7afc116f18fa9821e44d561
so to create a new account a node published the hash: 25ab3b38f7afc116f18fa9821e44d561
When they "create their first block" they need to include the hash fb469d7ef430b0baf0cab6c436e70375 which can be easily checked to be correct from their initially published hash to be the "previous hash" (and cannot be reversed due to the fact that crypto hashes are irreversible).
For their next block they would need to publish 098f6bcd4621d373cade4e832627b4f6 and they would "run out of the ability to create new blocks" once they have got this far.
Apart from weak seeds (and MD5 for example purposes) can anyone explain any serious technical issues with this idea?
|
|
|
I like the idea of taking a random photo (with a camera that has no internet capabilities) and then downloading the photo to an offline computer and taking a SHA256 of the photo file.
Easy to do - and hard to screw up IMO (you could attach a simple web cam to the offline computer to make this even easier).
|
|
|
This is much clearer to me now - thanks for the great input.
|
|
|
Nonce is a 32 bit Unsigned Integer.
There is a "second nonce" though isn't there (I seem to recall that)?
|
|
|
Increment the timestamp by one second for each header?
Issue a separate work request for each thread?
Okay - got it now. Nice to learn something new.
|
|
|
Okay - but how does each thread have its own "unique block header"?
I don't know the ins and outs of the way that mining is done so maybe I am missing something obvious here.
|
|
|
Why would it be any faster to search through nonce values in a different order?
Agreed - but if you as the hasher had say 10 threads that could hash simultaneously wouldn't it make more sense to divide up the "nonce range" into 10?
|
|
|
Well one transaction in particular is always distinct: the coinbase. Every miner will be paying their winnings to a different address. In the case of pooling, pools usually put a worker-distinguisher in the coinbase field of coinbase transaction to keep the work of the hashers they are paying distinct.
Of course - silly that I didn't see that - thanks for the clarification (now it makes sense why starting at 0 for the nonce is what you'd do - although I guess if you were running multiple threads as a hasher then you might have them each start with a different nonce).
|
|
|
Absolutely not. They are working on block headers which have a different merkel root, always. Existing mining protocols do not even have a facility to set the nonce position/range.
I guess I still don't understand the details of this part - is that due to them using different txs? Perhaps you could explain that a little clearer for someone like me that doesn't quite understand it.
|
|
|
They all start at zero (or any other number) it doesn't matter as they're all working on work which is merkle root distinct.
Wouldn't they be *repeating the same work* if they started with the same nonce?
|
|
|
My guess is that mining pools probably allocate a different starting *nonce* to each miner (but I haven't looked into it).
|
|
|
OTOH, QR-video would work. But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.
I actually already split up GPG private key into 2 QR codes for the CIYAM Safe so I do understand the size issues but I really don't think it is very hard to work with multiple QR codes. I guess having something that identified "how many images are coming" could be more handy though (as a header with the receiver then able to verify they have got everything).
|
|
|
Whilst what you have done does sound quite impressive - did you not consider just using QR codes instead?
(much more reliable and simpler compared to using audio)
Am pretty sure even etotheipi has changed his mind about QR codes.
|
|
|
Although I won't go as far as bitpop I would certainly say "don't use them" as their fees (charged to the *buyer*) are simply ridiculous.
|
|
|
Yes - I get now that the small amounts were being sent in *order to leave graffiti" - funnily enough I was actually one of the people who first requested blockchain.info to allow messages to be added to txs (in order to tag "tasks" for my own system - although I never ended up actually doing that).
|
|
|
Yeah - mostly just stupid stuff - hadn't even realised that this "top 100" website existed.
It is surprising to me that someone would risk having such a huge amount in a single address.
|
|
|
Thanks - so it is the richest single address - I wonder why all the small amounts with messages were being sent to it.
|
|
|
Is that supposed to be the DPR stash?
If so it is rather interesting that all of those funds have now moved.
|
|
|
The accounts "feature" of Bitcoin has never been particularly useful (and have heard of very few people that actually use it because of the way that it works).
For anyone familiar with "accounting" it does not function in the way that you'd think it should (it was more designed for "user accounts" but as the Bitcoin wallet itself doesn't scale up no large websites have used it - or at least have only used it for a short time until they realise it kills their wallet performance).
I would tend to think that "removing" it would indeed be a good idea.
|
|
|
|