From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
Date: Thu, 13 Jul 2017 00:10:55 -0300 [thread overview]
Message-ID: <CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]
Some responses..
>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
> (the largest possible transaction today is 1mb minus the block
> overheads). The maximum resource usage for maliciously crafted 1MB
> transaction is enormous and permitting two of them greatly exacerbates
> the existing vulnerability.
>
>
I think that limiting the maximum transaction size may not be the best
possible solution to the N^2 hashing problem, yet it is not a bad start.
There are several viable soft-forking solutions to it:
1- Soft-fork to perform periodic reductions in the maximum non-segwit
checksigs per input (down to 20)
2- Soft-fork to perform periodic reductions in the number of non-segwit
checksigs per transaction. (down to 5K)
3- Soft-fork to perform periodic reductions in the amount of data hashed by
non-segwit checksigs.
Regardless which one one picks, the soft-fork can be deployed with enough
time in advance to reduce the exposure. The risk is still low. Four years
have passed since I reported this vulnerability and yet nobody has
exploited it. The attack is highly anti-economical, yet every discussion
about the block size ends up citing this vulnerability.
,
> > Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB
>
> But in a worst case the result would be 8MB, which this document fails
> to mention.
>
I will mention this worst case in the BIP.
Even if artificially filling the witness space up to 8 MB is
anti-economical, Segwit exacerbates this problem because each witness byte
costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
than before. I think the guilt lies more in Segwit discount factor than in
the plain block size increase.
I would remove the discount factor altogether, and add a fixed (40 bytes)
discount for each input with respect to outputs (not for certain input
types), to incentivize the cleaning of the UTXO set. A discount for inputs
cannot be used to bloat an unlimited number of blocks, because for each
input the attacker needs to first create an output (without discount).
There is no need to incentivize removing the signatures from blocks,
because there is already an incentive to do so to save disk space.
>
> > Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".
>
> This means that BIP-91 and your proposal are indistinguishable on the
> network, because the string "segsignal" is merely a variable name used
> in the software.
>
> No, it is exposed to the rpc mining interface (getblocktemplate). It must
be redefined, even if it's not a consensus change.
>
[-- Attachment #2: Type: text/html, Size: 4011 bytes --]
next prev parent reply other threads:[~2017-07-13 3:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 22:25 Sergio Demian Lerner
2017-07-07 22:44 ` Matt Corallo
2017-07-07 23:25 ` Gregory Maxwell
2017-07-07 23:22 ` Gregory Maxwell
2017-07-13 3:10 ` Sergio Demian Lerner [this message]
2017-07-13 3:19 ` Sergio Demian Lerner
2017-07-07 23:27 ` Luke Dashjr
2017-07-07 23:38 ` Gregory Maxwell
2017-07-08 6:30 ` Erik Aronesty
2017-07-08 13:28 ` Btc Drak
[not found] ` <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
2017-07-10 11:50 ` Sergio Demian Lerner
2017-07-10 18:38 ` Jorge Timón
2017-07-12 8:15 ` Tom Zander
2017-07-12 12:38 ` Jonas Schnelli
2017-07-12 17:38 ` Jorge Timón
2017-07-13 19:19 ` Sergio Demian Lerner
2017-07-13 19:48 ` Andrew Chow
2017-07-13 21:18 ` Charlie 'Charles' Shrem
2017-07-14 13:50 ` Erik Aronesty
2017-07-12 1:06 ` Luke Dashjr
2017-07-12 15:41 ` Aymeric Vitte
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='CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com' \
--to=sergio.d.lerner@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/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