So I wasn't following the discussion for a few days and now it feels like things are exploding, so much new stuff here!
So let me first reiterate what I said in Gavin's BU-critique thread: IMO with our limited resources, we really want to focus on the core features of BU first, including a well-written patch set for block size (meaning: including a test suite etc.), and then start 'our own thing'. (Which I think will probably
eventually necessarily lead to larger deviation from Core in terms of the code base).
I think we do not lack people grasping Bitcoin to a high degree, but we simply do lack devs at the moment.
It is great that we have such a flurry of so many ideas and proposals around and I think this is also a another sure sign that something else was and is broken in Core: The arrogance of parts of the dev team did a great deal of damage to the fostering of a creative and inventive community. I remember people suspecting this effect in action in the debates on reddit and what is going on here now is pretty much proof of that suppressive effect having existed. Politburos will succumb to group-think (a danger around here, too!) and aren't that creative at some point anymore. This feels like a lot of fresh air now. Oh and happy new years, by the way
Along these lines: I feel that as much as we want new BUIPs, I think we're going to want BUIPs voting on prioritizing other BUIPs soon...
Some ideas and opinions on the posts in the last couple days:
-----
Maybe I am still not seeing a fundamental error in my line of thinking, but if the protocol (and most/all full nodes) would enforce UTXO commitments, don't we get truly better security than 'just trusting the miners'?
I mean:
Lets say we have a hard fork that makes all nodes calculate some determined UTXO merkle tree and lets them put the root hash into the block header.
Further, one can put the cumulative amount of unspent outputs at every level into the merkle tree. This would give you a nice and easy way to make sure that the inflation schedule is adhered to. The root node of the UTXO (and maybe also STXO) tree would be [amount, hash], with amount necessarily summing to the total amount of issued coins since genesis, which as we all know is a fixed formula just depending on block height.
So this would solve, as far as I can see, the problem of miners printing themselves unlimited Bitcoins.
Remains the problem that miners reprint history and for example expire some coins at their own choice.
I think the security and trust assumptions in this area are complex, but I see it this way:
Some people run full nodes today.
I have to trust other people that they want to continue running the Bitcoin network and continue running to run full nodes that I can connect to, or else my coins are worthless. I think the idea that Bitcoin is trustless because I can verify everything since genesis in some sense is a very weird - and on some level even
wrong - approximation. A single node that I own that contains transaction history is worthless without a network of other nodes existing that are like-minded.
With UTXO commitments, I'd go from trusting at least some other people wanting to continue to run full nodes to at least some other people continuing to run honest full nodes. Just a very small section of honest nodes would be enough, as they could all produce the necessary fraud proofs should miners collectively start to misbehave.
Now, if UTXOs are used to allow 'less-than-archive full nodes' that forget
some history, I can still let my full node request history from a sufficiently long period back, such as a year or a couple of years, and start validating from the UTXO back then plus all transactions that happened since then, and make sure that all those transactions that happened since then follow all applicable rules.
This would, I think, create a chain of interlinked 'trusting the network to be honest for any larger stretch of time', which I personally think is totally sufficient for a smoothly functioning Bitcoin network.
Furthermore: I think this latter danger with such an approach of miners dropping old coins could be further alleviated by those people who would be affected (owners of old coins that miners nefariously want to 'forget') setting up tracking of their coins through the UTXO trees. This should be a comparatively low amount of data and would be enough to produce fault proofs that his or her coins are being fraudulently dropped. For a very small fee, I could insure my coins against such an action - which might also be a way to pay archive nodes.
Additonally, a schedule to coalesce old UTXOs (being unspent for a long while) together could be implemented that means that old-coin-owners just have to update themselves yearly or so with a comparatively small set of data.
I share Gavin's 'UTXO uh-oh' thoughts because the UTXO set is the only thing that is growing and can grow very fast and needs to be stored (currently) and if hardware doesn't keep up, we would eventually need to implement a scheme to separate the UTXOs into an active and inactive set and shelve those away in a way that has as small amount of additional pain as possible for old coin holders.
-----
The complaint about comments is, but I think the complaint that there should be a test suite is not cosmetic. Testsuites are painful to write but they do add a lot of confidence regarding the correctness of the code. I'd love to find the time to grok Gavin's test suite and port it over to BU, and even said/promised I'll look into it, but didn't find any time yet...
Yes, and that's why I think
@theZerg made a good compromise given the limited resources: Test the real thing under the best conditions possible (testnet) and then hope that it works. Which is indeed something very different than untested code (which almost
never works...)
Yes, I agree that we should follow the heritage of Core's conventions in this area as much as necessary - unless it makes sense (with a sufficient argument) to do otherwise.
-----
@Inca,
@rocks,
@VeritasSapere and the whole RBF discussion:
I personally think RBF is unneeded and I think there will always be a boundary of things we won't include - for example, people could argue that BU is only Unlimited when it includes a multi-player Tetris clone that allows games between BU full nodes and that it also contains a full reimplementation of Monkey Island as an easter egg... ;-)
So I mostly agree with
@rocks in
post #4385 on this issue.
I think a way out of this and similar issues without too much hateful arguments
within our community is that of prioritization: I hope most can see that well tested and documented blocksize code is more important than a fancy way to deal with RBF, for example, so I'd vote for first doing that.
Of course, if someone submits a PR from outside that implements a nice way to deal with RBF, the resource requirements on
@theZerg (or who else might work on this in the position of a BU'ler ...) to pull it are of course a lot less than doing the full implementation, so the cost calculation changes and so the prioritization changes...
-----
@Richy_T,
post #4383:
Thank you, though this obviously wasn't a lot of work. One way to attack this (or improve the estimate, depending on where you are coming from) would be looking at storage cost in more detail. I think there is probably a small but non-negligible term that makes cost of storage not a constant but a linear function with time.
I like the idea of
eventual O(1) Bitcoin. Meaning pruning and some kind of coalescing/commitments. This of course also relates to the UTXO stuff above.
