From: Mark F <mark@friedenbach•org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Date: Wed, 17 Apr 2024 17:46:23 -0700 (PDT) [thread overview]
Message-ID: <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> (raw)
In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3245 bytes --]
On Wednesday, March 27, 2024 at 4:00:34 AM UTC-7 Antoine Poinsot wrote:
The only beneficial case I can remember about the timewarp issue is
"forwarding blocks" by maaku for on-chain scaling:
http://freico.in/forward-blocks-scalingbitcoin-paper.pdf
I would not qualify this hack of "beneficial". Besides the centralization
pressure of an increased block frequency, leveraging the timewarp to
achieve it would put the network constantly on the Brink of being seriously
(fatally?) harmed. And this sets pernicious incentives too. Every
individual user has a short-term incentive to get lower fees by the
increased block space, at the expense of all users longer term. And every
individual miner has an incentive to get more block reward at the expense
of future miners. (And of course bigger miners benefit from an increased
block frequency.)
Every single concern mentioned here is addressed prominently in the
paper/presentation for Forward Blocks:
* Increased block frequency is only on the compatibility chain, where the
content of blocks is deterministic anyway. There is no centralization
pressure from the frequency of blocks on the compatibility chain, as the
content of the blocks is not miner-editable in economically meaningful
ways. Only the block frequency of the forward block chain matters, and here
the block frequency is actually *reduced*, thereby decreasing
centralization pressure.
* The elastic block size adjustment mechanism proposed in the paper is
purposefully constructed so that users or miners wanting to increase the
block size beyond what is currently provided for will have to pay
significantly (multiple orders of magnitude) more than they could possibly
acquire from larger blocks, and the block size would re-adjust downward
shortly after the cessation of that artificial fee pressure.
* Increased block frequency of compatibility blocks has no effect on the
total issuance, so miners are not rewarded by faster blocks.
You are free to criticize Forward Blocks, but please do so by actually
addressing the content of the proposal. Let's please hold a standard of
intellectual excellence on this mailing list in which ideas are debated
based on content-level arguments rather than repeating inaccurate takes
from Reddit/Twitter.
To the topic of the thread, disabling time-warp will close off an unlikely
and difficult to pull off subsidy draining attack that to activate would
necessarily require weeks of forewarning and could be easily countered in
other ways, with the tradeoff of removing the only known mechanism for
upgrading the bitcoin protocol to larger effective block sizes while
staying 100% compatible with un-upgraded nodes (all nodes see all
transactions).
I think we should keep our options open.
-Mark
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4245 bytes --]
next prev parent reply other threads:[~2024-04-18 0:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 18:10 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-03-26 19:11 ` [bitcoindev] " Antoine Riard
2024-03-27 10:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-03-27 18:57 ` Antoine Riard
2024-04-18 0:46 ` Mark F [this message]
2024-04-18 10:04 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-04-25 6:08 ` Antoine Riard
2024-04-30 22:20 ` Mark F
2024-05-06 1:10 ` Antoine Riard
2024-06-17 22:15 ` Eric Voskuil
2024-06-18 8:13 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-18 13:02 ` Eric Voskuil
2024-06-21 13:09 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-24 0:35 ` Eric Voskuil
2024-06-27 9:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-28 17:14 ` Eric Voskuil
2024-06-29 1:06 ` Antoine Riard
2024-06-29 1:31 ` Eric Voskuil
2024-06-29 1:53 ` Antoine Riard
2024-06-29 20:29 ` Eric Voskuil
2024-06-29 20:40 ` Eric Voskuil
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=62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoindev@googlegroups.com \
/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