[bitcoin-dev] A Segwit2x BIP

[bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Hello,

Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.

This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.

You can find the BIP draft in the following link:

https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki

Reference source was kindly provided by the Segwit2x group.

Best regards,
 Sergio.

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Matt Corallo]

This is horribly under-specified (ie not possible to implement from what
you've written, and your implementation doesn't match at all, last I heard).

> Specification

> The plain block size is defined as the serialized block size without
> witness programs.
> Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".

This is not a protocol change. I have no idea why you included it in the
"specification" section.

> If segwit2x (BIP91 signal) activates at block N, then block N+12960
> activates a new plain block size limit of 2 MB (2,000,000 bytes). In
> this case, at block N+12960 a hard-fork occurs.

This is not a hard fork, simply adding a new limit is a soft fork. You
appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
did not increase the block size, your specification here matches that
original change, and does not increase the block size.

> The block that activates the hard-fork must have a plain block size
> greater than 1 MB.

There is no hard fork, and this would violate consensus rules. Not sure
what you mean. If you do add a hard fork to this BIP, you really need to
flip the hard fork bit.

> Any transaction with a non-witness serialized size exceeding 1,000,000
> is invalid.

This is far from sufficient to protect from DoS attacks, you really
should take a look through the mailing list archives and read some of
the old discussions on the issues here.

Matt

On 07/07/17 18:25, Sergio Demian Lerner via bitcoin-dev wrote:
> Hello,
> 
> Here is a BIP that matches the reference code that the Segwit2x group
> has built and published a week ago. 
> 
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
> 
> You can find the BIP draft in the following link:
> 
> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
> 
> Reference source was kindly provided by the Segwit2x group.
> 
> Best regards,
>  Sergio.
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] A Segwit2x BIP

[Gregory Maxwell]

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.

I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.

The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty.  Nowhere does this specification provide
justification or assurance that this is at all safe.  The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe.   This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.

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.

> 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.

> This is considered safe by many users, companies, miners and academics [2].

The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.

The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.

> 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.

> If segwit2x (BIP91 signal) activates at block N,

The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?

> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption

Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions.  There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.

> and buy time for more comprehensive solutions to be developed and tested

In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees.  It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.

It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.

Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )

Re: [bitcoin-dev] A Segwit2x BIP

[Gregory Maxwell]

On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is not a hard fork, simply adding a new limit is a soft fork. You
> appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
> did not increase the block size, your specification here matches that
> original change, and does not increase the block size.

Indeed, their code previously did not increase the blocksize but it
was adjusted at the last minute to do so-- so it may actually do that
now. Because they don't appear to have implemented any tests for it, I
wouldn't be too surprised if it still didn't work at all but also
wouldn't be surprised if it did.

You are correct that the specification text appears to refer to the
prior change that did not. (In my response I just assumed that it
meant what they actually did-- good catch).

Re: [bitcoin-dev] A Segwit2x BIP

[Luke Dashjr]

> Maximum transaction size is kept, to maximize compatibility with current
> software and prevent algorithmic and data size DoS's.

IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if 
on Segwit transactions (so in effect, nearly 4 MB transactions are possible). 
This probably doesn't make the hashing problem worse, however it should be 
made clear in the BIP.

> 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 [1]. This is considered safe
> by many users, companies, miners and academics [2].

Citations do not support the claim.

> The plain block size is defined as the serialized block size without
> witness programs.

This is deceptive and meaningless. There is no reason to *ever* refer to the 
size of the block serialised without witness programs. It is not a meaningful 
number.

> Deploy a modified BIP91 to activate Segwit. The only modification is that
> the signal "segsignal" is replaced by "segwit2x".

What is modified here? "segsignal" does not appear in the BIP 91 protocol at 
all...

> If segwit2x (BIP91 signal) activates at block N, then block N+12960
> activates a new plain block size limit of 2 MB (2,000,000 bytes). In this
> case, at block N+12960 a hard-fork occurs.

A "plain block size limit" of 2 MB would be a no-op. It would have literally 
no effect whatsoever on the network rules.

Furthermore, this does not match what btc1/Segwit2x currently implements at 
all. The actual implementation is: If Segwit (via deployment method) activates 
at block N, then block N+12960 activates a new weight limit of 8M (which 
corresponds to a size of up to 8,000,000 bytes).

> Any transaction with a non-witness serialized size exceeding 1,000,000 is
> invalid.

What is the rationale for excluding witness data from this measurement?

> In the short term, an increase is needed to continue to facilitate network
> growth, and buy time...

Actual network growth does not reflect a pattern that supports this claim.

> This reduces the fee pressure on users and companies creating on-chain
> transactions, matching market expectations and preventing further market
> disruption.

Larger block sizes is not likely to have a meaningful impact on fee pressure. 
Any expectations that do not match the reality are merely misguided, and 
should not be a basis for changing Bitcoin.

Luke

Re: [bitcoin-dev] A Segwit2x BIP

[Gregory Maxwell]

On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Larger block sizes is not likely to have a meaningful impact on fee pressure.
> Any expectations that do not match the reality are merely misguided, and
> should not be a basis for changing Bitcoin.

I think it's very clear that they will in the very short term
(https://anduck.net/bitcoin/fees/4320_blocks.php  note the rate drops
when demand falls below supply). But I agree with you if you mean a
somewhat longer term e.g. a year out.

Re: [bitcoin-dev] A Segwit2x BIP

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

- The BIP91 portion of the fork seems OK to me.  There are some issues with
timing, but since this is for miner coordination of segwit activation, and
has little to do with other network users, it could be included as an
option.   (I'm a fan of adding options;plugins, etc. to Bitcoin... some
others aren't.)

- This hard fork portion of the proposal is being deployed with "emergency"
speed... even though there is not an emergency on the network today that I
am aware of.   If enacted, it will certainly result in two chains - and
with no replay protection..  The results of this will be confusing - two
ledgers with many transactions appearing on both and others appearing only
on one.

- The BIP should be modified to provide evidence and justification for the
timeline that is consistent with the level of risk the network would bear
if it were enacted.

- The coercion used to drive production of this BIP is mired in a
misinterpretation of BIP9 and sets a precedent for Bitcoin that may
undermine the value prospect of all cryptocurrency in general.   For this
reason alone - even if all of the engineering concerns and timelines are
improved - even assigning this BIP a number could be considered
irresponsible.

- If you still want to code up a fork for the Bitcoin network, consider
starting with Luke's hard fork code and changing the rates of growth as
needed for your desired effect.   Also you might want to read this first
(code references are in there):
https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase .
Plans are already underway for a hard fork, for reasons that have nothing
to do with block size, but could include a timeline for a block size growth
consistent with global average residential bandwidth growth.

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

I am utterly appalled by this proposal both technically, ethically, and by
the process which it has adopted. Hard forks require consensus from the
entire ecosystem in order to prevent a fork, funds loss, confusion and harm
to the robust guarantees of the Bitcoin system has thus far displayed.

I know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
<https://pastebin.com/kktB1kaw> unless
you are an approved member
<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.

The linked coded doesn't uniquely identify itself on the network by
user-agent, something all distinct implementations have done to date.

The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.

I cannot not support this proposal in the current form and timeline, nor do
I support the coercion that has been used behind closed doors to try and
gain more support (not limited to, but including approaching company
investors to twist arms and veiled threats of blacklisting companies from
further funding/collaboration).

I think the best you can hope for this hard fork proposal is for it to be
quietly ignored.



On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
>
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
>  Sergio.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4105 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 4519 bytes --]

Thank you for all your comments. I will improve the BIP based on the
technical suggestions received.

On the subjective/political side that has slipped into this discussion.
Skip this part if not interested in politics.

Regarding the timeline, its certainly rather short, but also is the UASF
BIP 148 ultimatum.

If Bitcoin were a democracy and we had somehow a way to securely perform a
referendum, then this will solve easily. But neither is true. At least now.

More than 80% of the miners and many users are willing to go in the
Segwit2x direction. With the support and great talent of the Bitcoin Core
developers, Segwit2x activation will not cause any major disruptions.
Without Core, there will be a temporary split. Both sides will have to
hard-fork.

I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
own vision, is not so bad.

On Sat, Jul 8, 2017 at 6:19 PM, Brian Hoffman <brian@ob1.io> wrote:

> I don't feel threatened by investors. You're full of shit btcdrak.
>
> Proofread your emails. You just declared support for segwit2x.
>
> On Jul 8, 2017, at 9:28 AM, Btc Drak via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
> I am utterly appalled by this proposal both technically, ethically, and by
> the process which it has adopted. Hard forks require consensus from the
> entire ecosystem in order to prevent a fork, funds loss, confusion and harm
> to the robust guarantees of the Bitcoin system has thus far displayed.
>
> I know this is a draft, but you are seeking reviews of a proposal that has
> just a few weeks remaining before deployment (where "technical review" is
> pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless
> you are an approved member
> <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
> making it totally unworkable and irresponsible. For example, exactly how
> are other implementations supposed to adopt the BIP in such a short
> timeframe? For all the talk of how important "alternative implementations"
> are, how does this rash and rushed action promote an ecosystem of multiple
> implementors? By encouraging fast upgrades, you are actually centralizing
> the ecosystem even further.
>
> The linked coded doesn't uniquely identify itself on the network by
> user-agent, something all distinct implementations have done to date.
>
> The draft BIP text looks like an afterthought and doesn't actually specify
> the proposal in enough detail to implement from the text. By contrast for
> example, BIP141 has a level of detail which allowed others to implement
> segwit without looking at any reference code (which consequently results to
> more confidence and testing of the specification all round). The Bitcoin
> system has a market cap of over $40bn supported by a robust and reliable
> network and your proposal is an offence to all Bitcoin has achieved because
> due to it's the strong foundations.
>
> I cannot not support this proposal in the current form and timeline, nor
> do I support the coercion that has been used behind closed doors to try and
> gain more support (not limited to, but including approaching company
> investors to twist arms and veiled threats of blacklisting companies from
> further funding/collaboration).
>
> I think the best you can hope for this hard fork proposal is for it to be
> quietly ignored.
>
>
>
> On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> Here is a BIP that matches the reference code that the Segwit2x group has
>> built and published a week ago.
>>
>> This BIP and code satisfies the requests of a large part of the Bitcoin
>> community for a moderate increase in the Bitcoin non-witness block space
>> coupled with the activation of Segwit.
>>
>> You can find the BIP draft in the following link:
>>
>> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-
>> draft-sergiolerner-segwit2x.mediawiki
>>
>> Reference source was kindly provided by the Segwit2x group.
>>
>> Best regards,
>>  Sergio.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6414 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Jorge Timón]

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.

This is correct. If you are trying to imply that makes the short
timeline here right, you are falling for a "tu quoque" fallacy.

> More than 80% of the miners and many users are willing to go in the Segwit2x
> direction.

There's no logical reason I can think of (and I've heard many attempts
at explaining it) for miners to consider segwit bad for Bitcoin but
segwitx2 harmless. But I don't see 80% hashrate support for bip141, so
your claim doesn't seem accurate for the segwit part, let alone the
more controversial hardfork part.

I read some people controlling mining pools that control 80% of the
hashrate signed a paper saying they would "support segwit
immediately". Either what I read wasn't true, or the signed paper is
just a proof of the signing pool operators word being something we
cannot trust.

So where does this 80% figure come from? How can we trust the source?

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

It would be unfortunate to split the network into 2 coins only because
of lack of patience for deploying non-urgent consensus changes like a
size increase or disagreements about the right time schedule.
I think anything less than 1 year after release of tested code by some
implementation would be irresponsible for any hardfork, even a very
simple one.

Re: [bitcoin-dev] A Segwit2x BIP

[Luke Dashjr]

On Monday 10 July 2017 11:50:33 AM Sergio Demian Lerner via bitcoin-dev wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF
> BIP 148 ultimatum.

BIP148 began with 8 months lead time, reduced to 5 months from popular request 
and technical considerations. There is nothing about BIP148 that compels an 
attempted hardfork 90 days later - that could just as well have been 18 
months.

> More than 80% of the miners and many users are willing to go in the
> Segwit2x direction. With the support and great talent of the Bitcoin Core
> developers, Segwit2x activation will not cause any major disruptions.

That's not true at all. Based on my observations, only approximately 20% of 
the community follow Core's technical lead without significant consideration 
of their own - and who knows if that would change if Core were to suggest 
clearly-unsafe block size increases, or attempted to force a hardfork against 
consensus. Even with Core's support, many people would oppose the hardfork 
attempt, and it would fail.

> Without Core, there will be a temporary split. Both sides will have to
> hard-fork.

Segwit2x's hardfork does not compel the remaining Bitcoin users to also 
hardfork.

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

I concur, but I disagree your approach has any possibility of a united 
Bitcoin. The only way to get that today, would be to do Segwit+Drivechain, not 
Segwit+Hardfork.

Luke

Re: [bitcoin-dev] A Segwit2x BIP

[Tom Zander]

On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and 
tested for much longer than that.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] A Segwit2x BIP

[Jonas Schnelli]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]


> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.

Tested? Where?
However, the hardfork part may be out there for a long time but  _is still broken_.

/jonas

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Aymeric Vitte]

Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit :
> Even with Core's support, many people would oppose the hardfork 
> attempt, and it would fail.

Why with or without Core support are you sure that it will fail, what
can those that are opposing the hardfork attempt do (with or without
Core) and what does "fail" mean here in fact?

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [bitcoin-dev] A Segwit2x BIP

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.


Not true. It's different code on top of segwit. The first attempt in btc1
(very recent) didn't even increased the size (because it changed the
meaningless "base size" without touching the weight limit. As for the
current code, I don't think it has been properly tested today, let alone
"for mucj longer than 1 year.
Anyway, I said, one year from tested release. Segwitx2 hasn't been
released, has it? If so, too late to discuss a bip imo, the bip may end up
being different from what has been released due to feedback (unless it is
ignored again, of course).


--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner]

[-- 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 --]

Re: [bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.

On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> 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: 4617 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

The BIP has been updated.

Changes:
- The technical spec has been improved: now the block size increase is
specified in terms of weight and not in terms of bytes.
- The increase in the maximum block sigops after HF has been documented.
- Comments added about the worst case block size.

Happy weekend! And don't forget to start signaling something before block
475776 !  It's just 90 blocks away.
Bit 1 or 4,1 or whatever you wish, but please signal something.

To the moon!


On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> > I think anything less than 1 year after release of tested code by some
> > implementation would be irresponsible for any hardfork, even a very
> > simple one.
>
> Good news!
>
> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.
>
>
> Not true. It's different code on top of segwit. The first attempt in btc1
> (very recent) didn't even increased the size (because it changed the
> meaningless "base size" without touching the weight limit. As for the
> current code, I don't think it has been properly tested today, let alone
> "for mucj longer than 1 year.
> Anyway, I said, one year from tested release. Segwitx2 hasn't been
> released, has it? If so, too late to discuss a bip imo, the bip may end up
> being different from what has been released due to feedback (unless it is
> ignored again, of course).
>
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4076 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Andrew Chow]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

What's special about block 475776?


On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> The BIP has been updated.
>
> Changes:
> - The technical spec has been improved: now the block size increase is
> specified in terms of weight and not in terms of bytes.
> - The increase in the maximum block sigops after HF has been documented.
> - Comments added about the worst case block size.
>
> Happy weekend! And don't forget to start signaling something before block
> 475776 !  It's just 90 blocks away.
> Bit 1 or 4,1 or whatever you wish, but please signal something.
>
> To the moon!
>
>
> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev@lists.
>> linuxfoundation.org> wrote:
>>
>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
>> > I think anything less than 1 year after release of tested code by some
>> > implementation would be irresponsible for any hardfork, even a very
>> > simple one.
>>
>> Good news!
>>
>> Code to support 2x (the hard fork part of the proposal) has been out and
>> tested for much longer than that.
>>
>>
>> Not true. It's different code on top of segwit. The first attempt in btc1
>> (very recent) didn't even increased the size (because it changed the
>> meaningless "base size" without touching the weight limit. As for the
>> current code, I don't think it has been properly tested today, let alone
>> "for mucj longer than 1 year.
>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>> being different from what has been released due to feedback (unless it is
>> ignored again, of course).
>>
>>
>> --
>> Tom Zander
>> Blog: https://zander.github.io
>> Vlog: https://vimeo.com/channels/tomscryptochannel
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>
> ----------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5044 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Charlie 'Charles' Shrem]

[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]

Andrew,

Block 475776 and block 477792 (July 26) are the last 2 difficulty
adjustment periods before Aug 1st.

Charlie

On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What's special about block 475776?
>
> On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The BIP has been updated.
>>
>> Changes:
>> - The technical spec has been improved: now the block size increase is
>> specified in terms of weight and not in terms of bytes.
>> - The increase in the maximum block sigops after HF has been documented.
>> - Comments added about the worst case block size.
>>
>> Happy weekend! And don't forget to start signaling something before block
>> 475776 !  It's just 90 blocks away.
>> Bit 1 or 4,1 or whatever you wish, but please signal something.
>>
>> To the moon!
>>
>>
>> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>>
>>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
>>> > I think anything less than 1 year after release of tested code by some
>>> > implementation would be irresponsible for any hardfork, even a very
>>> > simple one.
>>>
>>> Good news!
>>>
>>> Code to support 2x (the hard fork part of the proposal) has been out and
>>> tested for much longer than that.
>>>
>>>
>>> Not true. It's different code on top of segwit. The first attempt in
>>> btc1 (very recent) didn't even increased the size (because it changed the
>>> meaningless "base size" without touching the weight limit. As for the
>>> current code, I don't think it has been properly tested today, let alone
>>> "for mucj longer than 1 year.
>>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>>> being different from what has been released due to feedback (unless it is
>>> ignored again, of course).
>>>
>>>
>>> --
>>> Tom Zander
>>> Blog: https://zander.github.io
>>> Vlog: https://vimeo.com/channels/tomscryptochannel
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 7050 bytes --]

Re: [bitcoin-dev] A Segwit2x BIP

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

While BIP91 is probably not terribly harmful, because the vast majority of
nodes and users are prepared for it - the hard fork portion of this BIP is
being deployed like an emergency patch or quick bug fix to the system.

Please consider updating the BIP to include some justification for the
urgency of the consensus change, and the reasons for not delaying until a
better engineered solution (spoonet, BIP103, etc.) can be deployed.


On Thu, Jul 13, 2017 at 3:19 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The BIP has been updated.
>
> Changes:
> - The technical spec has been improved: now the block size increase is
> specified in terms of weight and not in terms of bytes.
> - The increase in the maximum block sigops after HF has been documented.
> - Comments added about the worst case block size.
>
> Happy weekend! And don't forget to start signaling something before block
> 475776 !  It's just 90 blocks away.
> Bit 1 or 4,1 or whatever you wish, but please signal something.
>
> To the moon!
>
>
> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
>> > I think anything less than 1 year after release of tested code by some
>> > implementation would be irresponsible for any hardfork, even a very
>> > simple one.
>>
>> Good news!
>>
>> Code to support 2x (the hard fork part of the proposal) has been out and
>> tested for much longer than that.
>>
>>
>> Not true. It's different code on top of segwit. The first attempt in btc1
>> (very recent) didn't even increased the size (because it changed the
>> meaningless "base size" without touching the weight limit. As for the
>> current code, I don't think it has been properly tested today, let alone
>> "for mucj longer than 1 year.
>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>> being different from what has been released due to feedback (unless it is
>> ignored again, of course).
>>
>>
>> --
>> Tom Zander
>> Blog: https://zander.github.io
>> Vlog: https://vimeo.com/channels/tomscryptochannel
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5507 bytes --]