From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Great Consensus Cleanup Revival
Date: Tue, 26 Mar 2024 12:11:28 -0700 (PDT) [thread overview]
Message-ID: <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com> (raw)
In-Reply-To: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4549 bytes --]
Hi Poinsot,
I think fixing the timewarp attack is a good idea, especially w.r.t safety
implications of long-term timelocks usage.
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
Shall we as a community completely disregard this approach for on-chain
settlement throughput scaling ?
Personally, I think you can still design extension-block / side-chains like
protocols by using other today available
Bitcoin Script mechanisms and get roughly (?) the same security /
scalability trade-offs. Shall be fine to me to fix timewarp.
Worst-block validation time is concerning. I bet you can do worst than your
examples if you're playing with other vectors like
low-level ECC tricks and micro-architectural layout of modern processors.
Consensus invalidation of old legacy scripts was quite controversial last
time a consensus cleanup was proposed:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html
Only making scripts invalid after a given block height (let's say the
consensus cleanup activation height) is obviously a
way to solve the concern and any remaining sleeping DoSy unspent coins can
be handled with newly crafted and dedicated
transaction-relay rules (e.g at max 1000 DoSy coins can be spent per block
for a given IBT span).
I think any consensus boundaries on the minimal transaction size would need
to be done carefully and have all lightweight
clients update their own transaction acceptance logic to enforce the check
to avoid years-long transitory massive double-spend
due to software incoordination. 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-byte
as witness elements are only used for higher layers protocols semantics ?
Shall get its own "only-after-height-X" exemption, I think.
Making coinbase unique by requesting the block height to be enforced in
nLocktime, sounds more robust to take a monotonic counter
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
compare to your mining competitors. Better if it doesn't introduce a new
DoS vector at mining job distribution and control.
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
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
code to get right :)
Best,
Antoine
Le 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+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5738 bytes --]
next prev parent reply other threads:[~2024-03-26 19:15 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 ` Antoine Riard [this message]
2024-03-27 10:35 ` [bitcoindev] " '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
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=dc2cc46f-e697-4b14-91b3-34cf11de29a3n@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