On Tue, Feb 09, 2016 at 10:00:44PM +, Matt Corallo wrote:
> Indeed, we could push for more place by just always having one 0-byte,
> but I'm not sure the added complexity helps anything? ASICs can never be
> designed which use more extra-nonce-space than what they can reasonably
> assume will a
On 02/09/16 22:10, Luke Dashjr wrote:
> On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote:
>> Indeed, we could push for more place by just always having one 0-byte,
>> but I'm not sure the added complexity helps anything? ASICs can never be
>> designed which use more ex
On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote:
> Indeed, we could push for more place by just always having one 0-byte,
> but I'm not sure the added complexity helps anything? ASICs can never be
> designed which use more extra-nonce-space than what they can reasonably
Oops, forgot to reply to your last point.
Indeed, we could push for more place by just always having one 0-byte,
but I'm not sure the added complexity helps anything? ASICs can never be
designed which use more extra-nonce-space than what they can reasonably
assume will always be available, so we m
Thanks for keeping on-topic, replying to the proposal, and being civil!
Replies inline.
On 02/09/16 09:00, Anthony Towns via bitcoin-dev wrote:
> On Mon, Feb 08, 2016 at 07:26:48PM +, Matt Corallo via bitcoin-dev wrote:
>> As what a hard fork should look like in the context of segwit has neve
> 2) In order to prevent significant blowups in the cost to validate
> [...] and transactions are only allowed to contain
> up to 20 non-segwit inputs. [...]
There is two kind of hard fork, the one who breaks things, and the one who
does not.
Restricting the non-segwit inputs would disrupt lots of
On Mon, Feb 08, 2016 at 07:26:48PM +, Matt Corallo via bitcoin-dev wrote:
> As what a hard fork should look like in the context of segwit has never
> (!) been discussed in any serious sense, I'd like to kick off such a
> discussion with a (somewhat) specific proposal.
> Here is a proposed outl
On Mon, Feb 08, 2016 at 02:36:47PM -0800, Simon Liu via bitcoin-dev wrote:
> > 1) The segregated witness discount is changed from 75% to 50%. The block
> > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> > maximum block size of 3MB and a "network-upgraded" block size of rou
Look, if we’re going to declare something an emergency, we cannot on the one
hand say things like: "I strongly believe bitcoin has no place in the world if
the fee raise much higher than a few cents per typically-sized transaction”,
and on the other declare that there is an emergency worth redef
gop*size) < some_value . This allows
> calculation without actually running the script.
>
>
> -Original Message-
> From: bitcoin-dev-boun...@lists.linuxfoundation.org
> [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Matt
> Corallo via bitcoin-dev
> Sent:
> 1) The segregated witness discount is changed from 75% to 50%. The block
> size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> maximum block size of 3MB and a "network-upgraded" block size of roughly
> 2.1MB. This still significantly discounts script data which is kept out
>
Dev
Subject: [bitcoin-dev] On Hardforks in the Context of SegWit
Hi all,
I believe we, today, have a unique opportunity to begin to close the book on
the short-term scaling debate.
First a little background. The scaling debate that has been gripping the
Bitcoin community for the past half year has
Hi all,
I believe we, today, have a unique opportunity to begin to close the
book on the short-term scaling debate.
First a little background. The scaling debate that has been gripping the
Bitcoin community for the past half year has taken an interesting turn
in 2016. Until recently, there have b
13 matches
Mail list logo
