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
urgenc
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
What's special about block 475776?
On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev
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 th
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 weeken
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.ler...@gmail.com> wrote:
> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size
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
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 har
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
> 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
signature.asc
Description: Message signed with OpenPGP
_
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)
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 noth
On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
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" fall
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 1
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 kn
- 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
On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
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
> 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 pro
On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
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
> origina
On Fri, Jul 7, 2017 at 10:25 PM, 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.
I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just
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 Se
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.
21 matches
Mail list logo