From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Date: Wed, 24 Apr 2024 23:08:31 -0700 (PDT) [thread overview]
Message-ID: <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com> (raw)
In-Reply-To: <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 10647 bytes --]
Hi Maaku,
> 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.
Somehow, I'm sharing your concerns on preserving the long-term evolvability
w.r.t scalability options
of bitcoin under the security model as very roughly describer in the paper.
Yet, from my understanding
of the forwarding block proposal as described in your paper, I wonder if
the forward block chain could
be re-pegged to the main bitcoin chain using the BIP141 extensible
commitment structure (assuming
a future hypothetical soft-fork).
From my understanding, it's like doubly linked-list in C, you just need a
pointer in the BIP141 extensible
commitment structure referencing back the forward chain headers. If one
wishes no logically authoritative
cross-chain commitment, one could leverage some dynamic-membership
multi-party signature. This
DMMS could even be backup by proof-of-work based schemes.
The forward block chain can have higher block-rate frequency and the number
of block headers be
compressed in a merkle tree committed in the BIP141 extensible commitment
structure. Compression
structure can only be defined by the forward chain consensus algorithm to
allow more efficient accumulator
than merkle tree to be used".
The forward block chain can have elastic block size consensus-bounded by
miners fees on long period
of time. Transaction elements can be just committed in the block headers
themselves, so no centralization
pressure on the main chain. Increased block frequency or block size on the
forward block chain have not
effect on the total issuance (modulo the game-theory limits of the known
empirical effects of colored coins
on miners incentives).
I think the time-warp issues opens the door to economically non-null
exploitation under some scenarios
over some considered time periods. If one can think to other ways to
mitigate the issue in minimal and
non-invasive way w.r.t current Bitcoin consensus rules and respecting
un-upgraded node ressources
consumption, I would say you're free to share them.
I can only share your take on maintaining a standard of intellectual
excellence on the mailing list,
and avoid faltering in Reddit / Twitter-style "madness of the crowd"-like
conversations.
Best,
Antoine
Le vendredi 19 avril 2024 à 01:19:23 UTC+1, Antoine Poinsot a écrit :
> 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.
>
>
> You are the one being dishonest here. Look, i understand you came up with
> a fun hack exploiting bugs in Bitcoin and you are biased against fixing
> them. Yet, the cost of not fixing timewarp objectively far exceeds the
> cost of making "forward blocks" impossible.
>
> As already addressed in the DelvingBitcoin post:
>
> 1. The timewarp bug significantly changes the 51% attacker threat
> model. Without exploiting it a censoring miner needs to continuously keep
> more hashrate than the rest of the network combined for as long as he wants
> to prevent some people from using Bitcoin. By exploiting timewarp the
> attacker can prevent everybody from using Bitcoin within 40 days.
> 2. The timewarp bug allows an attacking miner to force on full nodes
> more block data than they agreed to. This is actually the attack leveraged
> by your proposal. I believe this variant of the attack is more likely to
> happen, simply for the reason that all participants of the system have a
> short term incentive to exploit this (yay lower fees! yay more block
> subsidy!), at the expense of the long term health of the system. As the
> block subsidy exponentially decreases miners are likely to start playing
> more games and that's a particularly attractive one. Given the level of
> mining centralization we are witnessing [0] i believe this is particularly
> worrisome.
> 3. I'm very skeptical of arguments about how "we" can stop an attack
> which requires "weeks of forewarning". Who's we? How do we proceed, all
> Bitcoin users coordinate and arbitrarily decide of the validity of a block?
> A few weeks is very little time if this is at all achievable. If you add on
> top of that the political implications of the previous point it gets
> particularly messy.
>
>
> I've got better things to do than to play "you are being dishonest! -no
> it's you -no you" games. So unless you bring something new to the table
> this will be my last reply to your accusations.
>
> Antoine
>
> [0] https://x.com/0xB10C/status/1780611768081121700
> On Thursday, April 18th, 2024 at 2:46 AM, Mark F <ma...@friedenbach•org>
> wrote:
>
> 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+...@googlegroups•com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com
> .
>
>
>
--
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/3e93b83e-f0ea-43b9-8f77-f7b044fb3187n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 14107 bytes --]
next prev parent reply other threads:[~2024-04-25 10:46 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
2024-04-18 10:04 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-04-25 6:08 ` Antoine Riard [this message]
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=3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--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