### VOTING is CLOSED for BUIPs 6,38,40,41 & 42 ###

[Roger_Murdock]

Signing address: 1AmtAAg9NK3j44y5RB6QBYrLnYJo3cJAtb

-----BEGIN BITCOIN SIGNED MESSAGE-----
BUIP006 FOR; BUIP038 AGAINST; BUIP040 FOR; BUIP041 AGAINST; BUIP042 FOR, jonny1000 AGAINST, eurovive AGAINST
-----BEGIN BITCOIN SIGNATURE-----
IGnkKejKK8i1KnOyLjteih1gIc4cpBYk32zUtjKKbfUJ6Hkm1yW+esfiXLzRDIP1UNB6LggUURO2rNo49P5AE0Y=
-----END BITCOIN SIGNED MESSAGE-----

 

[chriswilmer]

For people who are abstaining from any of the technical BUIPs... what will be the difference between the imminently released version of BU from the one we have now? I thought we needed to address some of these issues because the chinese miners wanted those features, no?

 

[Peter R]

@chriswilmer: yes the miners want (something like) BUIP040. What I don't understand though is why it's proposing to mark blocks > 1 MB as excessive by default. Doesn't this mean that everyone who downloads BU would need to manually increase their block size limit? The message we were sending with BU was that nodes could go ahead and increase their block size limits today by running BU -- if BUIP040 were implemented this wouldn't really be the case any longer.

I understand that mining nodes might want to run with a 1 MB "limit," but why not let the mining nodes adjust the defaults to achieve this (rather than setting the defaults at 1 MB and forcing all the common nodes to change their defaults)?

I am fine with the 1 MB TX size limit and the 20,000 sigops / MB limit, BTW. I just don't understand why we're decreasing the default excessive block size back to 1 MB.

EDIT: I MISUNDERSTOOD POINT #1 IN BUIP040. BUIP040 IS NOT PROPOSING TO CHANGE THE DEFAULT BLOCK SIZE LIMIT. SEE SOLEX'S RESPONSE BELOW.

 

[chriswilmer]

@Peter R : You have been following this more closely than me, but I thought that:

a) we wanted to have defaults to combat miner/node apathy
b) we needed the default to be 1 MB to prevent an attack where a still-minority-of-BU-miners start mining on a chain that has a >1 MB block but that the rest of the network is ignoring
[doublepost=1483205703][/doublepost]Also, I want to preempt someone interjecting by saying that this discussion should be moved elsewhere. It makes sense to me in the voting thread to have some discussion of the BUIPs we're voting on provided that everyone has read the detailed discussion threads already.

 

[solex]

@chriswilmerWhat I don't understand though is why it's proposing to mark blocks > 1 MB as excessive by default.

It's not blocks >1MB it is those <1MB where max sigops is exceeded (20k) which get marked excessive. This sets a safe base from which the >1MB blocks can have their transport-layer limits put into EC.
-----------

Voting to close in about 8 hours.

 

[Peter R]

@solex: thanks for clearing that up. Now it all makes sense. The title of the BUIP ("Emergent Consensus Parameters and Defaults for > 1MB blocks") is very confusing because Point #1 is actually about blocks <= 1 MB.

I am now adding a vote for BUIP040.

As far as BUIP038 / BUIP041, I'm partial to 038 but I'm voting for both because I think both would be improvements:

-----BEGIN BITCOIN SIGNED MESSAGE-----
BUIP038 YES
BUIP040 YES
BUIP041 YES
-----BEGIN SIGNATURE-----
1BWZe6XkGLcf6DWC3TFXiEtZmcyAoNq5BW
HyjvEUJTXVaefvFYrEVgSoHFWjKvsDHko2xFSOYm1scJOX0BHRzk4jF4+8SwdeYP4AOjxdG9b6A/y0jGMxYZ/Rw=
-----END BITCOIN SIGNED MESSAGE-----
[doublepost=1483216990][/doublepost]

@Peter R : You have been following this more closely than me, but I thought that:

a) we wanted to have defaults to combat miner/node apathy
b) we needed the default to be 1 MB to prevent an attack where a still-minority-of-BU-miners start mining on a chain that has a >1 MB block but that the rest of the network is ignoring

In my opinion, we want the default to be greater than 1 MB to combat node apathy. Miners can still mine with the default settings, but by changing their EB setting to 1 MB, the can also neutralize the (IMO very weak) attack threat you mentioned.

Anyways, it turns out I was confused and BUIP040 is NOT proposing to change the default excessive block size limit, so all is right in the universe .

 

[chriswilmer]

"so all is right in the universe"

Let's wait on such proclamations until we see what 2017 brings...

 

[sickpig]

to verify use this pub key: 1LwvkQTWmotqTosgBcK8kFPCKzW2BPiE1G

-----BEGIN BITCOIN SIGNED MESSAGE-----
BUIP006 AGAINST
BUIP038 AGAINST
BUIP040 FOR
BUIP041 FOR
BUIP042 jonny1000 AGAINST, eurovive AGAINST
-----BEGIN SIGNATURE-----
IAkFSAvXcFMy6O6JkR5yuizT3xEySn0byb3EmkPkANnSRr/y7fU5ywHPKv7WUtk+I+kAo/cWyHcv9fTk3w/qYww=
-----END BITCOIN SIGNED MESSAGE-----

I voted for to the BUIP040 with the implicit understanding that the same AD value used for excessive block will be used also for transaction size and sigops per MB constraints.

 

[solex]

Voting on these BUIPs is now closed.
A big thanks to all members who voted, and congratulations to the new members.

BUIP006 CLOSED 9:5
BUIP038 CLOSED 3:13
BUIP040 PASSED 12:4*
BUIP041 CLOSED 10:6
BUIP042 New Members:
1. @jake INDUCTED 16:0
2. @mike INDUCTED 16:0
3. @jonny1000 DECLINED 1:15
4. @Rogerver INDUCTED 16:0
5. @dgenr8 INDUCTED 16:0
6. @Emil Oldenburg INDUCTED 16:0
7. @Haiyang INDUCTED 16:0
8. @eurovive DECLINED 1:13
9. @Helvetian616 INDUCTED 16:0
10. @adamstgbit INDUCTED 16:0

Quorum 43/4

*Note: the two partial votes for BUIP040 should be considered as binding as separate items are enumerated in the BUIP and the margin to pass proves to require the two votes.

Edit: marking the totals as final.

 

[awemany]

Damnit, I missed it!

 

[jonny1000]

BUIP041 CLOSED 10:6

Good luck explaining BUIP041 to people at the same time you talk about how SegWit is too complicated!

I am amazed that this passed.

Satoshi had a simple genius vision, where the most work chain resolved the issue of conflicting transactions. You guys are now attempting to obviscate this to an extreme extent. It is now determined by seeing if the chain has AD confirmations, where AD is set locally and the value AD also varies by some complicated formula depending on blocksize. What a mess!

 

[Peter R]

"Good luck explaining BUIP041 to people at the same time you talk about how SegWit is too complicated!

I am amazed that this passed."

@jonny1000: "closed" means it did NOT pass.

 

[jonny1000]

@Peter R

Oh ok, thanks.

What does it mean then? What is required in order to pass?

 

[freetrader]

What is required in order to pass?

Enough people voting in favor of it...

Which btw is a good time to contemplate our BUIP lifecycle.

Right now, to me "Closed" does not mean that the same BUIP cannot try again, with some modifications. But I'm not sure how others see this.

 

[Roy Badami]

Well, the main problem is failure to reach the 50% quorum. BIP006 and BIP041 both had a majority in favour, but failed because we failed to achieve quorum. (The other votes that passed only did so because of the rule that allows a reduced 25% quorum if the vote passes with a 75% supermajority.)

I certainly don't think that BUIPs that seem to have general support should be considered out of the running for future consideration just because of a failure to achieve quorum.

EDIT: Without either 50% quorum being reached or a supermajority voting _against_ the BUIP, IMHO we haven't rejected it - we've simply failed to reach a decision in either direction. I don't think that lack of quorum, in and of itself, should necessarily be a reason to require modification to a BUIP before it could be put for another vote

 

[freetrader]

I agree with @Roy Badami on the issue that failure to reach quorum would not necessitate modification of a BUIP.

 

[AdrianX]

Can we keep the voting window open longer over traditional holiday periods. I spent the voting window living in a snow cave with no internet. But very happy to see the membership grow.

 

[solex]

@awemany, @AdrianX

The choice of the voting period was to allow development to complete so that we can have a new, official BU release in January. Unfortunate that you missed it, and the window can't be extended, but there will be more votes upcoming this year

@freetrader @Roy Badami
My view on rejected BUIPs is that they should not be quickly rewritten and re-presented for vote. Maybe after a year or two a similar / improved proposal can be considered, especially if the first vote was close. However, there is unlikely to be a hard and fast rule for this and some flexibility is needed at the discretion of the elected officials.

 

[freetrader]

@solex : Roy Badami's point which I agree with is that several BUIPs failed to reach quorum - they were not "rejected". In my view they should, at the discretion of their originators, be permitted to stand again at the next vote until they are either accepted or rejected with quorum.

I think the elected officials are best advised to not position themselves as gatekeepers of which BUIPs can be voted on. Otherwise we risk ending up with too much discretion.

Maybe after a year or two a similar / improved proposal can be considered

Instead of discretion I would prefer to see more explicit rules around maximal deferment and the rights of BUIP originators to request or waive inclusion in voting rounds, established through a procedural BUIP.

 

[solex]

@freetrader
Ah, I think there is a misunderstanding about quorum. It is 25% of the membership (excluding those dormant for >1 year). All the BUIPs reached quorum this time, which was 11 votes. However, three did not get the 75% majority required for passing when <50% of the members cast a vote.

In the case where quorum is not reached (which we have never seen yet), then yes, I think we should allow the same BUIP to go up for vote in the next round.

The amount of "gate-keeping" done is minimal. If a BUIP submitter claims a BUIP is complete, then it will go to vote next time (if a development BUIP then this includes liaison with the Developer), and includes the 2-week period for public comment. The discretion we would have is whether a new BUIP is the same as on old one that was previously rejected. Even then it could go for vote if members make a convincing case that the situation is different.