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

2016-02-08 Thread Samson Mow via bitcoin-dev
Gavin, please don't quote that list on the Classic website. It's horribly inaccurate and misleading to the general public. > That testing is happening by the exchange, library, wallet, etc providers > themselves. There is a list on the Classic home page: > > https://bitcoinclassic.com/ I know for

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

2016-02-08 Thread Peter Todd via bitcoin-dev
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

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

2016-02-08 Thread Tao Effect via bitcoin-dev
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

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

2016-02-08 Thread Tao Effect via bitcoin-dev
Hard forks should always come in response to some major crisis that all participants can agree is an actual crisis, as per the excellent rational here: http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/ And here: http://bitledger.info/hard-fork-risks-and-why-95-

Re: [bitcoin-dev] BIP Final status

2016-02-08 Thread Peter Todd via bitcoin-dev
On Mon, Feb 08, 2016 at 10:17:55PM +, Luke Dashjr via bitcoin-dev wrote: > Additionally, https://github.com/bitcoin/bips/pull/315 proposes to upgrade > five additional from Draft to Final status, and preferably needs ACKs from > the > champions of the BIPs: > > BIP 50: March 2013 Chain Fork

Re: [bitcoin-dev] BIP Final status

2016-02-08 Thread Luke Dashjr via bitcoin-dev
On Monday, February 08, 2016 10:41:00 PM Peter Todd wrote: > On Mon, Feb 08, 2016 at 10:17:55PM +, Luke Dashjr via bitcoin-dev wrote: > > Additionally, https://github.com/bitcoin/bips/pull/315 proposes to > > upgrade five additional from Draft to Final status, and preferably needs > > ACKs from

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

2016-02-08 Thread Simon Liu via bitcoin-dev
> 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 >

[bitcoin-dev] BIP Final status

2016-02-08 Thread Luke Dashjr via bitcoin-dev
https://github.com/bitcoin/bips/pull/314 proposes updating the status of many Accepted BIPs to Final: BIP 11: M-of-N Standard Transactions BIP 14: Protocol Version and User Agent BIP 21: URI Scheme BIP 22: getblocktemplate - Fundamentals BIP 23: getblocktemplate - Pooled Mining BIP 31: Pong messa

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

2016-02-08 Thread jl2012--- via bitcoin-dev
Thanks for this proposal. Just some quick response: 1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year of grace period. 2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141 if BI

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

2016-02-08 Thread Matt Corallo via bitcoin-dev
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