Thanks for your response BTC Drak, I will attempt to summarize your
points and respond to them:
* Some BIPs are not consensus critical -- True, see my response to Luke
* BIPs do not imply usage -- This I covered in my paper.
* Acceptance can be defined by actual use -- That's one way of doing it
Well let's see. All else being equal, if everybody uses difficulty to
buy big blocks during retarget interval 0, blocks and therefore money
issuance is slower during that interval. Then, the retargeting causes
it to be faster during interval 1. Subsidy got shifted from the
calendar period
I think the overlap of people who want to run a serious mining operation
and people who are unable to afford a slightly above average internet
connection is infinitesimally small.
2015-09-09 20:51 GMT+02:00 Jorge Timón :
>
> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" <
> bitcoin-dev@l
Does it really change the schedule when the next difficulty retarget
readjusts to an average of 10 minutes again?
On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is another concern regarding "flexcap" that was not discussed.
>
On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I propose to:
>
> a) assess what blocklimit is currently technically possible without
driving up costs of running a node up too much. Most systems currently
running a fullnode probably have so
There is another concern regarding "flexcap" that was not discussed.
A change to difficulty in response to anything BUT observed block
production rate unavoidably changes the money supply schedule, unless
you also change the reward, and in that case you've still changed the
timing even if not the
I propose to:
a) assess what blocklimit is currently technically possible without driving
up costs of running a node up too much. Most systems currently running a
fullnode probably have some capacity left.
b) set the determined blocklimit at the next reward halving
c) then double the blocksize l
Errata + clarity (in bold):
>
>
>- So in my proposal, if 2000+ *blocks *have a size >= 60% *of the
>current limit*, this is an indication that real transaction volume has
>increased and we're approaching a time where block could be filled to
>capacity without an increase. The block
