Hi Poinsot,
The only beneficial case I can remember about the timewarp issue is "forwarding blocks" by maaku for on-chain scaling:
I think any consensus boundaries on the minimal transaction size would need to be done carefully and have all lightweightclients update their own transaction acceptance logic to enforce the check to avoid years-long transitory massive double-spenddue to software incoordination.
However the BIP proposes to also make less-than-64-bytes transactions invalid. Although they are of no (or little) use, such transactions are not harmful. I believe considering a type of transaction useless is not sufficient motivation for making them invalid through a soft fork.
Making (exactly) 64 bytes long transactions invalid is also what AJ implemented in his pull request to Bitcoin-inquisition.
I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly by all transaction-relay backends and it's a mess in this area.
Quid if we have < 64 bytes transaction where the only witness is enforced to be a minimal 1-byteas witness elements are only used for higher layers protocols semantics ?
Making coinbase unique by requesting the block height to be enforced in nLocktime, sounds more robust to take a monotonic counterin 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-tripcompare to your mining competitors. Better if it doesn't introduce a new DoS vector at mining job distribution and control.
and b) it's already a lot of careful consensuscode to get right :)
Best,AntoineLe dimanche 24 mars 2024 à 19:06:57 UTC, Antoine Poinsot a écrit :Hey all,
I've recently posted about the Great Consensus Cleanup there: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710.
I'm starting a thread on the mailing list as well to get comments and opinions from people who are not on Delving.
TL;DR:
- 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;
- i believe it's more important to fix the timewarp bug than people usually think;
- 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;
- 64 bytes transactions should definitely be made invalid, but i don't think there is a strong case for making less than 64 bytes transactions invalid.
Anything in there that people disagree with conceptually?
Anything in there that people think shouldn't (or don't need to) be fixed?
Anything in there which can be improved (a simpler, or better fix)?
Anything NOT in there that people think should be fixed?
Antoine Poinsot
--
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/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com.
The only beneficial case I can remember about the timewarp issue is "forwarding blocks" by maaku for on-chain scaling: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.)
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 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.