Discussing HashCash-like improvement for bitcoin I brought it up as a necessary step:
... I'm thinking of a hybrid approach by giving space to wallets for participating in consensus without eliminating block miners. So many radical changes would be necessary for this to happen, on top of them getting rid of blockchain bloat and spv wallets, interchangeability of fee and work, defining total work of a block in a more general way, ....
SPV wallets constitute the most stupid part of bitcoin. They should be eliminated completely and unlike op I don't believe in a "semi-full node" replacement either. What he suggests,
snapshotting the UTXO, is the key to this agenda.
Using such a snapshot, has been proposed by many people earlier and ignored mostly because it was considered to be one of those "dangerous" proposals that need a hard fork to be implemented and in this weird community, bitcoin, had forking is cursed, ... long story.
@eurekafag AFAIK is
the first person who said something about it, july 2010(!), he used the term
snapshotting (it is why I used it above, to show my respect). The topic got no attention but another user, @Bytecoin rephrased it two days later and posted
a more comprehensive proposal.
Satoshi Nakamoto was still around and he never made a comment regarding this, Gavin Andersen didn't get it, neither @Theymos, ... just 2 and a half pages of non-productive discussions. Obviously in mid 2010 there were few blocks, few UTXOs and so many other problems and priorities.
Almost one year later, july 2011, Gregory Maxwell,
made a contribution to this subject he basically proposed something that later was termed,
UTXO Commitment, it was Merkle era, people were excited about the magical power of Merkle Trees and Maxwell proposed maintaining a Merkle Hash Tree of UTXO by full nodes that enables them to spot an unspent output efficiently while miners include the root of such a tree in coinbase transaction (later others proposed including it directly in block header) this way, 'lite clients' would be able to ask for proof of any tx input as being committed to the UTXO Merkle root included in latest blocks.
Basically, Maxwell's proposal needs a hard fork because full nodes MUST validate the UTXO Merkle root once it is provided:
What if the coinbase TXN included the merkle root for a tree over all open transactions, and this was required by the network to be accurate if it is provided.
'A hard fork?! Better to forget about it or at most put it, with all due respects, in the long list of hard-fork-wish-list', it was and still is how proposals could be handled in bitcoin community. Few replies, again non-productive and Maxwell's proposal got no more stem.
In August 2012, Andrew Miller published
a concrete proposal (and reference implementation) for a Merkle-tree of unspent-outputs (UTXOs) in bitcointalk: again no serious discussion.
Andrew explicitly mentioned his proposal as the one which "
belongs to Hardfork Wishlist".
Peter Todd went further and proposed
TXO Commitment by which he meant committing the Merkle hash root of the state to each transaction, he also introduced a
new concept 'delayed commitment' which is a key feature, imo.
I hate this hradfork fobia in bitcoin, bcash was not bad because of it being a hard fork it was bad because of the wrong technical direction they chose, imo. But I agree that a hardfork is not the decision a community should make very frequently and if there is a way to avoid it without too many sacrifices, it is better to be avoided.
So, the question is not whether op's idea is good (of course it is), the question is whether it could be implemented without a hardfork?
This is a bump for this thread, for a special purpose:
proving Gregory Maxwell wrong here:
I'm preparing a draft for this, but I'm really sick of doing work on problems that you guys in the team are not interested in.
And I'm really sick of your insulting lectures when you can't even bother to keep up on the state of the art in what's already been proposed.
Please spare me the excuses about how its other people's fault that you're not doing other things. You seem to have plenty of time to throw mud...
There are already existing designs for an assumevalid 'pruned sync'... but not enough hours in a day to implement everything immediately, and there are many components that have needed their own research (e.g.
rolling hashes like the ecmh, erasure codes to avoid having snapshots multiplying storage requirements, etc.).
If you want to help--great! But no one needs the drama. It's hard enough balancing all the trade-offs, considerations, and boring engineering without having to worry about someone being bent that other people aren't going out of their way to make them feel important. It's hard even to just
understanding all the considerations that other engineers express: So on one has time for people who come in like a bull in a china shop and don't put in that effort towards other people's work. It doesn't matter who you are, no one can guarantee that any engineering effort will work out or that its results will be used even if it does. The history of Bitcoin (as is the case in all other engineering fields) is littered with ideas that never (yet) made it to widespread use-- vastly more of them from the very people you think aren't listening to you than from you. That's just how engineering goes in the real world. Don't take it personally.
And it is the drama, usual Greg Maxwell ...
I don't think it is relevant to accuse people of not having done enough research when they are asking such a question, but the above quote and this whole thread tell everything about Maxwell's claim, I've been contributing to the subject for a while and nobody would ever accuse me about being noob here.
Speaking of software engineering ... a system that takes like an age to boot, is a natural candidate for practicing engineering principles, imo, I understand consensus based, decentralized, public protocols are hell of a new domain, but why should we stick with 'how engineering goes in the real world' of bitcoin when it has led us here?
Now, to be more on-rail with topic I was just wondering how would it look like a proper answer to my question
How do you think about the importance of bootstrap problem in bitcoin? Do you think a hypothetical safe approach to it, could ever exist and if so, how do you think about the importance and priority of upgrading bitcoin to support the new fast-sync feature?
For Gregory Maxwell as a prominent figure and a pro, it looks just more professional to say, I presume:
"
Yes, we do agree that a hypothetical solid solution to the bootstrap nightmare in bitcoin is of much interest and deserves to be considered as an implementation priority". No, really, doesn't it look more professional?
But how do you think about my highlighted question?
