[bitcoin-dev] A Segwit2x BIP

[Sergio Demian Lerner via bitcoin-dev]

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.

[Matt Corallo via bitcoin-dev]

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

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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev

Post by Matt Corallo via bitcoin-dev
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).

[Gregory Maxwell via bitcoin-dev]

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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 ?

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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. )

[Sergio Demian Lerner via bitcoin-dev]

Some responses..

Post by Gregory Maxwell via bitcoin-dev
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.

,

Post by Gregory Maxwell via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Gregory Maxwell via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

[Sergio Demian Lerner via bitcoin-dev]

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 <

Post by Sergio Demian Lerner via bitcoin-dev
Some responses..

Post by Gregory Maxwell via bitcoin-dev
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.
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.
,

Post by Gregory Maxwell via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Gregory Maxwell via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

[Luke Dashjr via bitcoin-dev]

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

[Gregory Maxwell via bitcoin-dev]

On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev

Post by Luke Dashjr via bitcoin-dev
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.

[Erik Aronesty via bitcoin-dev]

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

[Btc Drak via bitcoin-dev]

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 <

Post by Sergio Demian Lerner via bitcoin-dev
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Sergio Demian Lerner via bitcoin-dev]

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.

I don't feel threatened by investors. You're full of shit btcdrak.
Proofread your emails. You just declared support for segwit2x.
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 <

Post by Sergio Demian Lerner via bitcoin-dev
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev

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.

[Tom Zander via bitcoin-dev]

Post by Jorge Timón via bitcoin-dev
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.

[Jonas Schnelli via bitcoin-dev]

Post by Tom Zander via bitcoin-dev
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

[Jorge Timón via bitcoin-dev]

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <

Post by Jorge Timón via bitcoin-dev
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

[Sergio Demian Lerner via bitcoin-dev]

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 <

Post by Tom Zander via bitcoin-dev

Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Andrew Chow via bitcoin-dev]

What's special about block 475776?


On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
The BIP has been updated.
- 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 <

Post by Tom Zander via bitcoin-dev

Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

----------
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Charlie 'Charles' Shrem via bitcoin-dev]

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 <

Post by Andrew Chow via bitcoin-dev
What's special about block 475776?
On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <

Post by Sergio Demian Lerner via bitcoin-dev
The BIP has been updated.
- 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 <

Post by Jorge Timón via bitcoin-dev
On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <

Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Erik Aronesty via bitcoin-dev]

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 <

Post by Sergio Demian Lerner via bitcoin-dev
The BIP has been updated.
- 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 <

Post by Jorge Timón via bitcoin-dev
On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <

Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Luke Dashjr via bitcoin-dev]

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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

[Aymeric Vitte via bitcoin-dev]

Post by Luke Dashjr via bitcoin-dev
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