Hi Tomas,
I agree with Dustin that we don't want to have to trust the miners at the
individual level (ie: choosing timestamps) too much, but part of what these
protocols do is create mechanisms where we can (hopefully) trust them in
the aggregate. That being said, it's an interesting thought that you had
and I've been thinking about something similar. There is a (I hope)
particularly compelling argument presented at the end that I think lends at
least some merit to the concept. So, let's work through it a little:
To be on the safe side, it would probably need to be based not so much on
the time_from_last_block, but more on a median timestamp of the last N
blocks but N would need to be less than the number of blocks in a
difficulty adjustment period (so this whole thing would happen totally
within the normal difficulty cycle and not affect the difficulty calcs),
but we'll just call it time_from_last_block for now. If I understand you
correctly, we're basically saying that if hash power cut in half all of a
sudden, then as soon as the protocol/nodes realized it, the allowable
blocksize would be doubled. And if that same hashpower returned, then as
soon as the protocol realized it, the allowable max size would be halved.
The mechanism would need to be symmetric (more time_from_last_block -->
larger max_blocksize, and less time_from_last_block --> smaller max
blocksize) as otherwise you run the risk of growing the total size of the
chain in an unpredictable fashion.
One of the positive side effects (and I'm sure there are some negative ones
too) is that whenever a large chunk of hashpower unexpectedly leaves, this
mechanism which basically targets a "constant maximum transactional
throughput rate" would disproportionately reward those miners that stick
around and slog through the glut of hashpower, and proportionally punish
all miners (including those that stuck around) when they return. As an
example: in the recent BTC / BCH situation, where hashpower left and BTC's
blocktimes became slower than normal, there was one pool, Slush's pool,
that seemed to stick around BTC regardless. The mechanism we're discussing
here would have allowed Slush to mine larger blocks (and thereby earn more
fees for itself) during the time that the hashpower was absent.
Another interesting feature (bug?) of a mechanism like this is that it
would actually have punished all miners for temporarily defecting because,
since Slush was able to grow the allowable blocksize while they were gone,
then when they returned the max blocksize would shrink down to less than it
was before they left. Those miners returning to BTC would be causing the
time-between-blocks to be increasing, and therefore, under this proposed
mechanism, the max blocksize would be decreasing. Perhaps such a punitive
arrangement would have removed/lessened the incentive that any of those
miners had to temporarily leave in the first place? While that may be
desirable, its hard to know without further analysis whether this mechanism
would lessen the propensity for defection.
Now for the reason I do like the mechanism, presuming it could be
implemented safely. If we follow this logic all the way down and imagine a
situation where there is catastrophic loss of hashing power (governments
shut down all known large-scale mining operations), I think it's pretty
much assumed that a PoW network would do a hard-fork difficulty adjustment
(or in the worst case change PoW algorithms all together) in an effort to
broaden the number of people/nodes that can carry to torch forward. Let's
assume the network would try a difficulty adjustment first and try to coax
the current non-mining nodes into becoming miners in order to "save the
chain." With a mechanism like we're discussing here in place, the desired
effect of the hard-fork difficulty adjustment (namely to open mining up to
a larger group of nodes) I think might happen more naturally and with less
downtime/chaos (and at-minimum without a hard fork). This is because the
more time that passes, the more the mempool would grow, and the large the
acceptable max block size. In the extreme case, where only 1% of the
original hashpower remained, then, sure, even though your node would still
need to meet the difficulty requirement, the temptation to build a block
that is 100x bigger than normal (and earn all those fees!) so as to keep
the network's max throughput on track at a constant could become large
enough that literally most (previously non-mining) nodes that didn't have a
shot when compared to the "big guys" would begin mining. Similarly the big
guys would be in a mad scramble to get back online and nab mining that
giant goldmine of a large block!
Lastly, the big winner here would be (hopefully): users. This is because
while the miners contemplated in the above are playing games the honest
miners were able to hold down the fort and make sure that the max
transactional throughput rate stayed steady.
While I'm not certain this is the outcome/mechanism we want for grin's
network (especially since grin is very focused on keeping things simple
right now), it at least is an interesting direction to consider.
P.S. I'm also not certain that this mechanism doesn't pervert miner
incentives such that they actively try to reduce each other's network
connectivity. Then again that perversion exists in bitcoin as-is anyway,
and so far it seems to be ok.
P.P.S. Can this mechanism be gamed by large miners who collude to "cycle"
large amounts of hash power offline, let the max blocksize grow, then come
back online to grab the larger block? Perhaps, but since they would only be
getting one block subsidy for the block (the larger reward would be due to
fees), it seems they would be better off by not doing so and instead just
staying online as much as possible (which is what we want in the first
place!).
On Tue, Nov 21, 2017 at 1:00 AM, Dustin Dettmer <dustinpaysta...@gmail.com>
wrote:
> I wouldn't put so much trust in miners timestamps. I'm much more of a fan
> of building systems where we don't have to trust them.
>
> On Tue, Nov 21, 2017 at 12:53 AM Tomas Juočepis <tomasjuoce...@gmail.com>
> wrote:
>
>> Hello, grinners,
>>
>> what if block size limit of each newly found block would be linearly
>> proportional to time elapsed since last block? Stated another way, nodes
>> would consider a new block valid only if timestamp delta (new block
>> timestamp - last block timestamp) multiplied by some parameter of size/time
>> ratio is greater than the size of the new block. It seems that something
>> like this could produce a more constant transaction throughput in cases of
>> quickly varying applied pow rate ("hash rate") without affecting difficulty
>> adjustment.
>>
>> For example, consider the following block timestamp deltas (in minutes):
>> 10, 20, 30, 3, 5, 7, 5, 5, 5, 10 (total 100, average 10 (nominal))
>> With block sizes being constant, we get 10 blocks worth of size.
>> With block sizes linearly proportional to time delta, with slope
>> coefficient set so that nominal (target) time produces nominal block size,
>> we'd get same cumulative size (and therefore same cumulative consumed
>> network bandwidth), but transaction rate would be more even/consistent.
>>
>> Let's say we can fit 1000 txs in a block designed to be mined every 10
>> minutes. With the previous example, with constant size we'd have the
>> following:
>> t=10, 1000 txs confirmed
>> t=30, 2000 txs confirmed
>> t=60, 3000 txs confirmed
>> t=63, 4000
>> t=68, 5000
>> t=75, 6000
>> t=80, 7000
>> t=85, 8000
>> t=90, 9000
>> t=100, 10000
>> With time-delta-scaled size, we'd have:
>> t=10, 1000 txs
>> t=30, 3000 txs
>> t=60, 6000 txs
>> t=63, 6300 txs
>> t=68, 6800 txs
>> t=75, 7500 txs
>> t=80, 8000 txs
>> t=90, 9000 txs
>> t=100, 10000 txs
>>
>> Any thoughts? The main issue I see is gaming timestamps, but can't that
>> be solved by nodes not propagating blocks until timestamps are no longer
>> dated in the future? Miners could still risk and add a timestamp few
>> minutes into the future, but they would risk their block being orphaned if
>> another miner finds another block with a valid timestamp, thus propagating
>> through the network (before the future dated block can propagate).
>> --
>> Mailing list: https://launchpad.net/~mimblewimble
>> Post to : mimblewimble@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~mimblewimble
>> More help : https://help.launchpad.net/ListHelp
>>
>
> --
> Mailing list: https://launchpad.net/~mimblewimble
> Post to : mimblewimble@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help : https://help.launchpad.net/ListHelp
>
>
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
