[Bitcoin-ml] Solving the difficulty adjustment problem by asking the opposite question

Amaury Séchet deadalnix at gmail.com
Mon Aug 28 11:19:59 UTC 2017


No, it is completely different. Faking timestamp with the 2016 block
adjustment windows is not useful, as most block timestamps are not
considered in the computation, and not worth it for the last block of the
windows (the only that matter) as indeed you are 2h wiggle room over a 2
weeks period, which doesn't represent much.

In this case, one faking its own block timestamp is a way for one to
directly affect its block reward. This is completely different.

The fact that nobody was able to provide an analysis, or that not even
anybody seems to be able to notice the difference lead me to conclude that
this proposal wasn't thought through thoroughly. I think this is fair to
ask for simulation data and a threat analysis and each new message that do
not bring these is undermining the credibility of the proposal in my eyes.


2017-08-28 2:08 GMT+02:00 Jan Nightingale <turifex at protonmail.ch>:

> How do they hurt their bottom line by attacking BCH? Short how many coins
> you expect to mine profitably, mine them+send them to an exchange, claim
> the short with newly mined coins, go back to mining Core, Segwit2x or
> whatever.
>
> >considering timestamp are unreliable and can't be checked ex post facto,
> how is that secure in any way
>
> I already explained. The future blocks aren't going to be accepted by the
> network (which includes exchanges). So you can mine future blocks but they
> are useless at the moment. This gives other miners the profit incentive and
> time to orphan your time-travelling chain with earlier timestamps and equal
> or higher difficulty. Additionally, the more in the future your chain is,
> the higher the incentive to orphan it, because rewards depend on the time
> difference.
>
>
> -------- Original Message --------
> Subject: Re: [Bitcoin-ml] Solving the difficulty adjustment problem by
> asking the opposite question
> Local Time: August 28, 2017 1:56 AM
> UTC Time: August 27, 2017 11:56 PM
> From: deadalnix at gmail.com
> To: Bitcoin and related network protocol discussion <bitcoin-ml at lists.
> linuxfoundation.org>, Jan Nightingale <turifex at protonmail.ch>
>
> To the contrary, if coins being unstable is too damaging, they hurt their
> bottom line. And if they are not so damaging, then this problem is not that
> urgent and there is no need to freak out.
>
> Back to the proposal, considering timestamp are unreliable and can't be
> checked ex post facto, how is that secure in any way ?
>
> Le 28 août 2017 1:53 AM, "Jan Nightingale via bitcoin-ml" <
> bitcoin-ml at lists.linuxfoundation.org> a écrit :
>
>> I don't think another solution is possible at all.
>>
>> In >1-chain case all pure difficulty adjustments can only produce a
>> binary result: more profitable than other chains or not, taking into
>> account the entire coin maturity time, predicted difficulty changes, etc.
>> If the result is more profitable, all profit-maximizing power jumps. After
>> the coin stops being profitable, they jump out, and the only way to save
>> the chain is for some miner(s) to mine at a loss.
>> Stabilizing the block issuance by manipulating the difficulty is thus
>> IMPOSSIBLE. New strategies can only work temporarily until a new exploiting
>> strategy is developed.
>>
>> Why do simple strategies sort-of work in altcoins under similar
>> situations and without node enforcement? The most likely answer seems to be
>> that miners just aren't interested enough to start exploiting them, in
>> other words the particular mining market is very far from being efficient,
>> possibly due to the relatively small size. Alternatively, the majority is
>> unwilling to engage in hostile practices.
>>
>> Unfortunately none of this is true for sha256 mining, and Bitcoin Cash
>> can expect a lot of hostility and attacks.
>>
>> It's of course possible that the chain manages to survive without attacks
>> until it becomes the biggest one, but that's a risky bet to make.
>>
>>
>> -------- Original Message --------
>> Subject: Re: [Bitcoin-ml] Solving the difficulty adjustment problem by
>> asking the opposite question
>> Local Time: August 27, 2017 12:04 AM
>> UTC Time: August 26, 2017 10:04 PM
>> From: erik.beijnoff at gmail.com
>> To: Jan Nightingale <turifex at protonmail.ch>, Bitcoin and related network
>> protocol discussion <bitcoin-ml at lists.linuxfoundation.org>
>>
>> I think this is an interesting proposal that shouldn’t be dismissed too
>> easily.
>>
>> I also think that the possibilities for a miner to shift timestamps is
>> fairly limited due to network acceptance. It would probably be a one time
>> movement in one direction after which the timestamp will be firmly planted
>> at one end of the acceptable range.
>>
>> However, and this is probably a big issue, this is such a big deviation
>> from something tried and tested with Bitcoin etc. that the implications of
>> it would need to be tested over a longer time than we have. Therefore I
>> think it should be included in a list of suggestions, elaborated on, but to
>> switch to it is probably a too big deviation from what is currently
>> accepted by the network.
>>
>> Much appreciated that you propose a new way to attack the issue though.
>>
>> /Erik
>>
>>
>> > On 26 Aug 2017, at 22:08, Jan Nightingale via bitcoin-ml <
>> bitcoin-ml at lists.linuxfoundation.org> wrote:
>> >
>> > Additional points:
>> >
>> > Scenario - miners trying to manipulate difficulty/time:
>> > A miner mines a block that"s 30 second into the future with difficulty
>> 1. It"s not accepted by the network now, but it"s going to be 30 seconds
>> from now.
>> > I can mine on top of his chain, creating a t+60 block. Which means
>> waiting that long until it"s considered valid, risking an orphan. Or I can
>> orphan his block mining with difficulty 2 and wait "just" 30 seconds.
>> Orphaning is a much safer proposition.
>> >
>> > But then another miner comes, and also mines with difficulty 2, but
>> with the current timestamp, orphaning my block, as it"s earlier even though
>> the difficulty is equal.
>> >
>> > (1) it"s much easier to lower the timestamp in comparison to increasing
>> the difficulty
>> > (2) Mining a block with a future timestamp gives competing miners time
>> to mine something with at least equal difficulty but lower timestamp, so
>> lower timestamp makes an orphan much less likely.
>> > (3) As time=reward, the more in the future a block is, the more
>> incentive other miners have to orphan it.
>> >
>> > Due to these incentives timestamps should turn out to be as close to
>> the current time as possible.
>> >
>> > The difficulty increase process would continue until subsequent miners
>> decide that the expected profitability of mining on top of an existing
>> block is higher than the expected profitability of trying to orphan. Or
>> more likely, seeing the futility of too low difficulty miners are just
>> going to put in something reasonable, with low probability of getting
>> orphaned.
>> >
>> > Is there going to be more wasted hash power?
>> > I don"t see a fundamental reason why. There are going to be more
>> orphans, yes. However, the hashpower waste shouldn"t be much worse than the
>> current one. Current waste is invisible - as it"s much harder to create a
>> block. The only person who knows about stale shares is a miner and his
>> pool. With faster blocks it"s going to become globally visible, but actual
>> levels should be comparable.
>> >
>> > I admit it"s likely at the beginning there"s going to be an additional
>> hash power waste as miners are likely to try various difficulty strategies
>> to learn what works best.
>> >
>> >> -------- Original Message --------
>> >> Subject: [Bitcoin-ml] Solving the difficulty adjustment problem by
>> asking the opposite question
>> >> Local Time: August 26, 2017 5:48 PM
>> >> UTC Time: August 26, 2017 3:48 PM
>> >> From: bitcoin-ml at lists.linuxfoundation.org
>> >> To: bitcoin-ml at lists.linuxfoundation.org <
>> bitcoin-ml at lists.linuxfoundation.org>
>> >>
>> >> Hi,
>> >> I think the current approach - changing the difficulty based on past
>> block times - is impossible to do right in the presence of >1 chains with
>> the same POW. The 2-chain case is not even close to the worst one - what if
>> there are 3? A realistic short-term possibility! In the future, one can
>> imagine dozens of sha256 chains.
>> >>
>> >> Consider:
>> >> If one chain is more profitable, ALL profit-maximizing miners should
>> switch.
>> >> After difficulty drops enough so that the chain stops being
>> profitable, again, ALL profit-maximizing miners switch.
>> >> What this means: there"s no solution. No matter what the difficulty
>> algorithm is, enormous oscillations of hash power are unavoidable. It"s a
>> rabbit hole of introducing ever more complex strategies fixing the
>> particular exploitation methods of previous methods.
>> >>
>> >> Non-profit maximizing miners are impossible to model, as there are
>> infinite possible incentives. There"s also additional complexity arising
>> due to miners" switching lag - but again, imo that"s impossible to model as
>> it depends on the particular mining operation.
>> >>
>> >> Even if the 2-chain case could be solved this way (I"m skeptical) I
>> don"t believe it"s going to work in the >2 case, making the system fragile
>> and requiring another change.
>> >>
>> >> For this reason, I propose going to the bare fundamentals and turning
>> the difficulty system on its head. To quote Tom Harding "The combined
>> BTC+BCC system is very complex. I think more ideas need to be considered as
>> well.". The idea is radical but imo the only approach that could actually
>> work.
>> >>
>> >> What are the fundamentals in my opinion?
>> >> - we want X new coins per Y minutes according to the inflation
>> schedule - $desiredInflationPer10Minutes;
>> >> - we want the transaction capacity to be limited, equivalent to
>> $currentBlockLimit per Y minutes.
>> >>
>> >> Currently, Bitcoin, and to my knowledge all other POW coins, work by
>> observing (1) reducing the relation between those variables to a constant,
>> reducing the variables in the system to one - block time, and
>> >> (2) observing the block time on the live network and correcting the
>> difficulty in the desired direction.
>> >>
>> >> The system works because of an ephemeral network consensus - nodes
>> refusing to accept a block that"s too far in the future.
>> >>
>> >> The proposal:
>> >> - Instead of per block, make the rewards directly connected to time. A
>> block with a timestamp 600 seconds more than the previous one gets
>> $desiredInflationPer10Minutes; a block with 300 seconds more gets
>> $desiredInflationPer10Minutes/2 [0].
>> >> - Same for the block size limit - a block 300 seconds after the last
>> one gets $currentBlockLimit/2, 150 seconds $currentBlockLimit/4 etc [0].
>> >> - No minimum difficulty - miners can mine whatever difficulty they
>> want, however, the most valid chain rule stays the same - the highest
>> cumulative difficulty.
>> >> - To prevent excessive flooding with empty blocks, consecutive blocks
>> have to be at least 10 seconds apart. That"s completely arbitrary, 10
>> seconds just seem sensible to me.
>> >>
>> >> The desired outcome:
>> >> A stable equilibrium is reached and all oscillations are dampened.
>> Miners have the incentive to estimate the amount of competing hash power at
>> the moment and set their difficulty high enough so that there"s a
>> sufficiently low chance of getting orphaned, but low enough so that they
>> are producing blocks.
>> >>
>> >> A miner setting his difficulty too low will find out he"s wasting hash
>> power as all or most of his blocks are getting orphaned.
>> >> A miner setting his difficulty too high will find out he"s wasting
>> hash power as with a lower difficulty he could get more rewards that
>> wouldn"t be orphaned.
>> >>
>> >> As a result, the system self-corrects very fast, incentivizing miners
>> to use variables that are impossible to include in the pure past-block time
>> difficulty adjustment: current ratio of block rewards compared to other
>> chains and amount of competing hash power, possibly more.
>> >>
>> >> What about block time? Is that a problem? In my opinion, no - on the
>> contrary!
>> >> - a block header is only 80 bytes, so even one block every 10 seconds
>> means 4800B-80B=4720B of "waste" per 10 minutes - that"s nothing. [1]
>> >> - block confirmations get to be almost continuous. There"s some
>> initial period, let"s say 30 seconds, in which there"s a high risk of
>> orphans - but after that, confirmation strength grows very fast,
>> potentially making on-chain payments safe enough for even large in-person
>> shop payments! More useful as cash.
>> >> - there are probably going to be empty blocks even in the presence of
>> unconfirmed transactions, but note that the block size limit is defined the
>> same way - so there"s no capacity lost! Imo there"s no reason to prefer one
>> 8MB block per 10 minutes to, for example, 8x1MB in the same 10 minutes.
>> >>
>> >> Minor considerations:
>> >> - node DOS protection - a node accepting blocks under this scheme
>> could find itself DOSed with lots of spurious low-difficulty chains. This
>> problem already exists but would be exacerbated. However, that"s not a
>> consensus problem, so it can be dealt much more arbitrarily - by estimating
>> "reasonable" difficulty from external sources or other nodes.
>> >> [0] - there"s a very minor problem arising due to integer division
>> leading to loss of lowest bits. It could be ignored, leading to minusculely
>> lower inflation and/or size. Instead, I think accumulating the errors is
>> the right approach - ie. lost block reward appears as soon as it fits into
>> the uint64 amount, similar for size.
>> >> [1] - the $blockLimit per 10 minutes could be computed independently
>> of headers
>> >>
>> >> Regards,
>> >> Jan Nightingale
>> >
>> > _______________________________________________
>> > bitcoin-ml mailing list
>> > bitcoin-ml at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>>
>>
>>
>> _______________________________________________
>> bitcoin-ml mailing list
>> bitcoin-ml at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170828/ca7f76a8/attachment-0001.html>


More information about the bitcoin-ml mailing list