Future of Bitcoin

[CryingSofa]

@Alex

a PettyCompliant actor would need to have much more hash power than an honest one in order to do this consistently, otherwise they would only be able to do it when a half-empty block arrived very closely after a full one.

I’m not sure which situation you’re referring to. Could you explain a bit further, please? Just PettyCompliant mining or actively undercutting? I have tried to think about a few scenarios and I cannot follow your reasoning.

@Alex

Greg Maxwell wrote an interesting “rebuttal” to this paper already three years ago. His argument was that these issues were already well known, some mitigations had already been put in place (which the original paper ignored) and others were already in the works.

This is exactly what I was hoping for, thank you!

@Greg Maxwell

(2) Have wallets nlocktime new transactions that they create so they can only be included in the next block on the network or even later. This is implemented and deployed today (IIRC as of Bitcoin Core 0.11). This creates a population of transactions whos fees can only be obtained by moving forward.

(2b) adjust timebased locktime handling so that there is not an incentive for miners to dishonestly move their clock forward to allow them to accept not yet mature transactions. (Done, per BIP113 and locked into the network).

I think this should fix the issue I brought up. Glad to see that bitcoin is more responsive than @jmk fears:

@jmk

• Bitcoin developers already “changed the algorithm”, twice! One is called Bitcoin SV and the other is called Bitcoin Cash. They are no longer Bitcoin. If developers vote to make another change, it will be represented in (yet another) fork from Bitcoin. Meanwhile, Bitcoin will remain Bitcoin, and well, that’s kind of the whole point of a distributed ledger (aka blockchain).

@Dago

Given that the current development team is the one opposed to even changing the block size from 1MB to 2MB, I severely doubt they would agree to change something so fundamental.

I agree. I think this might be the reasoning:

@Greg Maxwell

(1) Having a meaningfully limited blocksize relative to transaction load. In this case, by meaningfully limited I mean such that there is almost always a backlog sufficient to make variance in the arrival times of blocks and fees moot. (If fees were nearly isotropic this alone would be enough, to the best of my current understanding… and most of the time we have several tens of megs of backlog, though not with remotely isotropic fees)

I’m not sure how fun this is for the users… It certainly seems desirable for technical reasons, but as a hypothetical user this does not excite me at all.