Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

> 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

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

As for your stages idea, I generally like the idea (and mentioned it may be a good idea in my proposal), but am worried about scheduling two hard-forks at onceLets do our first hard-fork first with the things we think we will need anytime in the visible future that we have reasonable designs

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] Question regarding Confidential Transactions

My understanding of the paper is that the blinding factor would be included in the extra data which is incorporated into the ring signatures used in the range proof. Although, since I think the range proof is optional for single output transactions (or at least, one output per transaction

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

I believe i've seen Luke say this several times before, but there are several more things that the majority of the devs agree should be in bitcoin. I would suggest to compile that list for your stage 3, so that you can have an hardfork that fixes most of those things, and there should be some

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

I am actually suggesting 1 hardfork, not 2. However, different rules are activated at different time to enhance safety and reduce disruption. The advantage is people are required to upgrade once, not twice. Any clients designed for stage 2 should also be ready for stage 3. -Original

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

Happy Lunar New Year Everyone! Gavin, > I suspect there ARE a significant percentage of un-maintained full > nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for > three reasons: The notion of large set ( 30% to 40% ) of un-maintained full nodes are not evident on the

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

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

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo wrote: > > There are 406 nodes total that falls under the un-maintained category, > which is below 10% of the network. > Luke also have some data here that shows similar results. >

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

> I love seeing data! I was considering 0.10 nodes as 'unmaintained' because it has been a long time since the 0.11 release. https://packages.gentoo.org/packages/net-p2p/bitcoin-qt The Gentoo package manager still has 0.10.2 as the most recent stable version. Getting a later version of the