First of all, thank you very much for answering the questions, and apologies for not having formulated them properly (fortunately that's not an irreparable mistake).
On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen <[email protected]> wrote: > On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón <[email protected]> wrote: >> >> 1) If "not now" when will it be a good time to let fees rise above zero? > > > Fees are already above zero. See > http://gavinandresen.ninja/the-myth-of-not-full-blocks When we talk about "fees" we're talking about different things. I should have been more specific. Average fees are greatly influenced by wallet and policy defaults, and they also include extra fees that are included for fast confirmation. I'm not talking about fast confirmation transactions, but about non-urgent transactions. What is the market minimum fee for miners to mine a transaction? That's currently zero. If you don't want to directly look at what blocks contain, we can also use a fee estimator and define a "non-urgent period", say 1 week worth of blocks (1008 blocks). The chart in your link doesn't include a 1008 blocks line, but the 15 blocks (about 2.5 hours) line seems to already show zero fees: http://img.svbtle.com/p4x3s7fn52sz9a.png So I reformulate the question: 1) If "not now", when will it be a good time to let the "market minimum fee for miners to mine a transaction" rise above zero? >> 2) When will you consider a size to be too dangerous for centralization? >> In other words, why 20 GB would have been safe but 21 GB wouldn't have >> been (or the respective maximums and respective +1 for each block >> increase proposal)? > > > http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized This just shows where the 20 GB come from, not why you would reject 21 GB. Let me rephrase. 2) Do you have any criterion (automatic or not) that can result in you saying "no, this is too much" for any proposed size? Since you don't think the consensus block size maximum limits mining centralization (as you later say), it must be based on something else. In any case, if you lack a criterion that's fine as well: it's never too late to have one. Would you agree that blocksize increase proposals should have such a criterion/test? >> 3) Does this mean that you would be in favor of completely removing >> the consensus rule that limits mining centralization by imposing an >> artificial (like any other consensus rule) block size maximum? > > > I don't believe that the maximum block size has much at all to do with > mining centralization, so I don't accept the premise of the question. Ok, this is an enormous step forward in the discussion, thank you. In my opinion all discussions will be sterile while we can't even agree on what are the positive effects of the consensus rule that supposedly needs to be changed. It's not that you don't care about centralization, it's that you don't believe that a consensus block size maximum limits centralization at all. This means that if I can convince you that the consensus block size maximum does in fact limit centralization in any way, you may change your views about the whole blocksize consensus rule change, you may even take back or change your own proposal. But let's leave that aside that for now. Regardless of the history of the consensus rule (which I couldn't care less about), I believe the only function that the maximum block size rule currently serves is limiting centralization. Since you deny that function, do you think the (artificial) consensus rule is currently serving any other purpose that I'm missing? If the answer is something along the lines of "not really, it's just technical debt", then I think you should be honest and consequent, and directly advocate for the complete removal of the consensus rule. I really think conversations can't really advance until we clarify the different positions about the discussed consensus rule current purpose. _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
