Hi Maaku, From reading back the "forward block" paper, while it effectively guarantees an on-chain settlment throughput increases without the necessity to upgrade old clients, one could argue the proof-of-work change on the forward chain (unless it's a no-op double-sha256) coupled with the subsidy schedule smoothing, constitutes a substantial change of the already-mined UTXO security model. You can use a lot of hash functions as proof-of-work primitive, though it doesn't mean they are relying on as strong assumptions or level of cryptanalysis. In fine, you could have poorly picked up hash function for the forward chain resulting in a lowering of everyone coins security (the > 100 TH/s of today is securing years old coins from block mined under < 1 TH/s). I hold the opinion that fundamental changes affecting the security of everyone coins should be better to be opted-in by the super-economic majority of nodes, including non-mining nodes. At the contrary, the "forward block" proposal sounds to make the point it's okay to update proof-of-work algorithm by a combined set of mining nodes and upgraded non-mining nodes, which could hypothetically lead to a "security downgrade" due to weaker proof-of-work algorithm used on the forward chain. While your papers introduce formalization of both full-node cost of validation and censorship resistance concepts, one could also add "hardness to change" as a property of the Bitcoin network we all cherishes. If tomorrow, 10% of the hahrate was able to enforce proof-of-work upgrade to the broken SHA-1, I think we would all consider as a security downgrade. Beyond, this is corect we have a diversity of old nodes used in the ecosystem, probably for block explorer and mempool websites. Yet in practice, they're more certainly vectors of weakness for their end-users, as Bitcoin Core has sadly a limited security fixes backport policy, which doesn't go as far as v0.8 for sure. That we can all deplore the lack of half-decade old LTS release policy for Bitcoin Core, like done by the Linux kernel is a legitimate conversation to have (and it would be indeed make it easier with libbitcoinkernel progress). I think we shall rather invite operators of oldest still-running nodes to upgrade to more recent versions, before to ask them to go through the analytical process of weighting all the security / scalability trade-offs of a proposal like "forward block". Finally, on letting options open to bump block inter-val as a soft-fork on the compatibility chain, I think one could still have a multi-stage "forward block" deployment, where a) a new difficutly adjustment algoritm with parameters is introduced bumping block inter-val for upgraded mining nodes e.g a block every 400 s in average and the b) re-use this block inter-val capacity increase for the forward chain flexible block size. Now why a miner would opt-in in such block-interval constraining soft-fork is a good question, in a paradigm where they still get the same block subsidy distribution. This is just a thought experiment aiming to invalidate the "as far as anyone can tell" statement on forclosing forever on-chain settlement throughput increase, if we fix the timewarp bug. Best, Antoine Le mercredi 1 mai 2024 à 09:58:48 UTC+1, Mark F a écrit : > Hi Antoine, > > That's a reasonable suggestion, and one which has been discussed in the > past under various names. Concrete ideas for a pegged extension-block side > chain go back to 2014 at the very least. However there is one concrete way > in which these proposals differ from forward blocks: the replay of > transactions to the compatibility block chain. With forward blocks, even > ancient versions of bitcoind that have been running since 2013 (picked as a > cutoff because of the probabilistic fork caused by v0.8) will see all > blocks, and have a complete listing of all UTXOs, and the content of > transactions as they appear. > > Does this matter? In principle you can just upgrade all nodes to > understand the extension block, but in practice for a system as diverse as > bitcoin support of older node versions is often required in critical > infrastructure. Think of all the block explorer and mempool websites out > there, for example, and various network monitoring and charting tools. Many > of which are poorly maintained and probably running on two or three year > old versions of Bitcoin Core. > > The forward blocks proposal uses the timewarp bug to enable (1) a > proof-of-work change, (2) sharding, (3) subsidy schedule smoothing, and (4) > a flexible block size, all without forcing any non-mining nodes to *have* > to upgrade in order to regain visibility into the network. Yes it's an > everything-and-the-kitchen-sink straw man proposal, but that was on purpose > to show that all these so-called “hard-fork” changes can in fact be done as > a soft-fork on vanilla bitcoin, while supporting even the oldest > still-running nodes. > > That changes if we "fix" the timewarp bug though. At the very least, the > flexible block size and subsidy schedule smoothing can't be accomplished > without exploiting the timewarp bug, as far as anyone can tell. Therefore > fixing the timewarp bug will _permanently_ cutoff the bitcoin community > from ever having the ability to scale on-chain in a backwards-compatible > way, now or decades or centuries into the future. > > Once thrown, this fuse switch can't be undone. We should be damn sure we > will never, ever need that capability before giving it up. > > Mark > > On Thursday, April 25, 2024 at 3:46:40 AM UTC-7 Antoine Riard wrote: > >> 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 >>> 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/5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n%40googlegroups.com.