Hi Poinsot,<div><br /></div><div>I think fixing the timewarp attack is a good idea, especially w.r.t safety implications of long-term timelocks usage.</div><div><br /></div><div>The only beneficial case I can remember about the timewarp issue is "forwarding blocks" by maaku for on-chain scaling:</div><div>http://freico.in/forward-blocks-scalingbitcoin-paper.pdf<br /></div><div><br /></div><div>Shall we as a community completely disregard this approach for on-chain settlement throughput scaling ?</div><div>Personally, I think you can still design extension-block / side-chains like protocols by using other today available</div><div>Bitcoin Script mechanisms and get roughly (?) the same security / scalability trade-offs. Shall be fine to me to fix timewarp.</div><div><br /></div><div>Worst-block validation time is concerning. I bet you can do worst than your examples if you're playing with other vectors like</div><div>low-level ECC tricks and micro-architectural layout of modern processors.</div><div><br /></div><div>Consensus invalidation of old legacy scripts was quite controversial last time a consensus cleanup was proposed:</div><div>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html<br /></div><div><br /></div><div>Only making scripts invalid after a given block height (let's say the consensus cleanup activation height) is obviously a</div><div>way to solve the concern and any remaining sleeping DoSy unspent coins can be handled with  newly crafted and dedicated</div><div>transaction-relay rules (e.g at max 1000 DoSy coins can be spent per block for a given IBT span).</div><div><br /></div><div>I think any consensus boundaries on the minimal transaction size would need to be done carefully and have all lightweight</div><div>clients update their own transaction acceptance logic to enforce the check to avoid years-long transitory massive double-spend</div><div>due to software incoordination. I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly by all transaction-relay</div><div>backends and it's a mess in this area. Quid if we have  &lt; 64 bytes transaction where the only witness is enforced to be a minimal 1-byte</div><div>as witness elements are only used for higher layers protocols semantics  ? Shall get its own "only-after-height-X" exemption, I think.</div><div><br /></div><div>Making coinbase unique by requesting the block height to be enforced in nLocktime, sounds more robust to take a monotonic counter</div><div>in the past in case of accidental or provoked shallow reorgs. I can see of you would have to re-compute a block template, loss a round-trip</div><div>compare to your mining competitors. Better if it doesn't introduce a new DoS vector at mining job distribution and control.</div><div><br /></div><div>Beyond, I don't deny other mentioned issues (e.g UTXO entries growth limit) could be source of denial-of-service but a) I think it's hard</div><div>to tell if they're economically neutral on modern Bitcoin use-cases and their plausible evolvability and b) it's already a lot of careful consensus</div><div>code to get right :)</div><div><br /></div><div>Best,</div><div>Antoine</div><div><br /></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">Le dimanche 24 mars 2024 à 19:06:57 UTC, Antoine Poinsot a écrit :<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hey all,
<br>
<br>I&#39;ve recently posted about the Great Consensus Cleanup there: <a href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710" target="_blank" rel="nofollow" data-saferedirecturl="https://www.google.com/url?hl=fr&amp;q=https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710&amp;source=gmail&amp;ust=1711565663390000&amp;usg=AOvVaw0H-vWJQFB5_UBHVBwhQ1qE">https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710</a>.
<br>
<br>I&#39;m starting a thread on the mailing list as well to get comments and opinions from people who are not on Delving.
<br>
<br>TL;DR:
<br>- i think the worst block validation time is concerning. The mitigations proposed by Matt are effective, but i think we should also limit the maximum size of legacy transactions for an additional safety margin;
<br>- i believe it&#39;s more important to fix the timewarp bug than people usually think;
<br>- it would be nice to include a fix to make coinbase transactions unique once and for all, to avoid having to resort back to doing BIP30 validation after block 1,983,702;
<br>- 64 bytes transactions should definitely be made invalid, but i don&#39;t think there is a strong case for making less than 64 bytes transactions invalid.
<br>
<br>Anything in there that people disagree with conceptually?
<br>Anything in there that people think shouldn&#39;t (or don&#39;t need to) be fixed?
<br>Anything in there which can be improved (a simpler, or better fix)?
<br>Anything NOT in there that people think should be fixed?
<br>
<br>
<br>Antoine Poinsot
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com</a>.<br />