From: "Joachim Strömbergson" <joachimstr@protonmail•com>
To: Braydon Fuller <braydon@purse•io>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Chain width expansion
Date: Tue, 15 Oct 2019 07:20:07 +0000 [thread overview]
Message-ID: <yKuDn4LKCA9-olIsgnJO7VqN3RE9BgZWEzLu6-k4wG30iHYDIJa6wjTBoYXU0zWCRyNCEvBb4xQw7qp0BDGBCR4zccI6kJ_4AnlsB9vc9L4=@protonmail.com> (raw)
In-Reply-To: <93649df9-27ab-abaf-00f3-da6c528344cc@purse.io>
> > [...] First you provide proof of your best block height via coinbase [...]
>
> So I don't think you can use the height in the coinbase for that
> purpose, as it's not possible to validate it without the previous
> headers. That's common for more than just the height.
You can fake it of course, but it means you are spending money for PoW and I can't see viable attack here. You can commit to either lower height than actual or higher height, if you are malicious. If it is lower, then your chain will look weaker with some heuristic based on PoW of the tip and the chain length. So you are not going to do that. It thus seem it only makes sense to commit to higher than actual height. OK, this could convince me to be interested in your chain over others. So let's say the real chain is 600k blocks, you claim 1m blocks, and you prove 1m height block to me. So I can ask you about
1) 2000 headers from the tip down
2) AND another proof of height for the block at 1m-2000.
To be able to provide that you need to have such a chain and you can reuse any real subchain from mainnet. It's still possible that you can deliver that, but not for high difficulty.
Now if time warp attack is blocked, you will have pretty hard time to create such a chain that would look strongest in cumulative work. I don't have actual numbers though, so I can't say this would mitigate everything.
> > [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
>
> In that case, it would take about 7 minutes of block time seconds for
> the next retarget period, every 2016 blocks, and the difficulty would
> adjust. The difficulty would adjust in that case as if 2 weeks of blocks
> had been mined in 7 minutes. For the difficulty to remain the same the
> time between blocks needs to be 10 minutes.
This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window.
next prev parent reply other threads:[~2019-10-15 7:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 0:38 Braydon Fuller
2019-10-04 8:20 ` David A. Harding
2019-10-04 19:51 ` Braydon Fuller
2019-10-11 21:24 ` Braydon Fuller
2019-10-04 23:31 ` Tier Nolan
2019-10-10 16:16 ` Braydon Fuller
2019-10-12 16:27 ` Tier Nolan
2019-10-12 17:56 ` Joachim Strömbergson
2019-10-12 20:46 ` Tier Nolan
2019-10-16 19:07 ` Braydon Fuller
2019-10-15 0:42 ` Braydon Fuller
2019-10-15 7:20 ` Joachim Strömbergson [this message]
2019-10-15 8:12 ` Braydon Fuller
2019-10-15 15:50 ` Joachim Strömbergson
2019-10-16 19:25 ` Braydon Fuller
2019-10-15 18:30 ` Tier Nolan
2019-10-15 0:38 ` Braydon Fuller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='yKuDn4LKCA9-olIsgnJO7VqN3RE9BgZWEzLu6-k4wG30iHYDIJa6wjTBoYXU0zWCRyNCEvBb4xQw7qp0BDGBCR4zccI6kJ_4AnlsB9vc9L4=@protonmail.com' \
--to=joachimstr@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=braydon@purse$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox