Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AD8B4259 for ; Wed, 24 May 2017 08:34:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C92961E2 for ; Wed, 24 May 2017 08:34:11 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1AD4A20819; Wed, 24 May 2017 04:34:11 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Wed, 24 May 2017 04:34:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=r9ECIA WG0mnowX2mxrfHuAUgfLTuxP6hJdDGN6XCKCY=; b=mNiIE+RtST6s7ETsoRUSY/ 7sLC8ltz0nbezSZeXhCAivw1nB4xetU1S0ORNswWW9kW/YFpqLEtIXUJ4hZ+tVXs t99M0U3c1pmViF74pqKjDtwvMaGGMOsEfTP8ItVg0vQ8jP3eHU3ULWJZVyWM9F2Y u74cvbi+OwVL/zQZiI76no3NWJTjGZ5yuDeCX9g/wUrWi0DgVC3pn9nc+T9MrgLi xzIFBPbPYJV8SIj8qPJlyzJWxEeIx9Oj/Sqtz7JJdd+JhxGGY6UiRI84Ec7nYMwo qcu1nh2CTObTy6WMadz1dR8NoF3sQObu0LTNlhSdTL+gDccxV5H50FIHK9N6R2eA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EB5AE9ED21; Wed, 24 May 2017 04:34:10 -0400 (EDT) Message-Id: <1495614850.2407540.986853224.2FB087C6@webmail.messagingengine.com> From: Tomas To: erik@q32.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149561485024075403" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694 Date: Wed, 24 May 2017 10:34:10 +0200 References: <1495536637.1801543.985680712.6B788409@webmail.messagingengine.com> In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 24 May 2017 10:01:25 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:34:12 -0000 This is a multi-part message in MIME format. --_----------=_149561485024075403 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, May 24, 2017, at 04:42, Erik Aronesty wrote: > Instead of block thresholds, use utxo bits to coordinate size changes > (larger and smaller should be allowed).> > There is no reason for miners to be involved in a decision to change > this aspects of the protocol. Plenty of other ways to coordinate. Miners cannot change the block size or any other rule without support of the users, because their blocks and coins would be rejected. This mechanism that Bitcoin brought us, has been working fine and I see no reason to change it with utxo bits. I *only* propose an optional way to synchronize changes without the need of off chain agreements, which seems like a simple improvement over the current situation. > > Otherwise someone can make it seem to a miner like 99pct of nodes are > ready for a larger weight.... even though that's false. I agree that the user agent signalling isn't very important, and I think that most of us aware that you cannot rely on counting them. > > On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" dev@lists.linuxfoundation.org> wrote:>> I have a proposal that would allow each user to optionally >> configure the>> maximum block weight at a support threshold. >> >> It recognizes that there is no need for off chain bickering, by >> providing a mechanism that lets each users freely choose their own >> parameters while still maintaining full coordination of any changes.>> >> The BIP can be found here: >> >> https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki>> >> It is worth noting that this proposal does neither gives more >> power to>> miners nor reduces decentralization. Miners still rely on their >> blocks>> being accepted by economic nodes to sell their minted coins. This >> proposal doesn't change that. >> >> Regards, >> Tomas van der Wansem >> bitcrust >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_----------=_149561485024075403 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

On Wed, May 24, 2017, at 04:42, Erik Aronesty wrote:
Instead of block thresholds, use utxo bits to coordinate size changes (larger and smaller should be allowed).

There is no reason for miners to be involved in a decision to change this aspects of the protocol.   Plenty of other ways to coordinate.

Miners cannot change the block size or any other rule without support of the users, because their blocks and coins would be rejected. This mechanism that Bitcoin brought us, has been working fine and I see no reason to change it with utxo bits.

I *only* propose an optional way to synchronize changes without the need of off chain agreements, which seems like a simple improvement over the current situation.



Otherwise someone can make it seem to a miner like 99pct of nodes are ready for a larger weight.... even though that's false.

I agree that the user agent signalling isn't very important, and I think that most of us aware that you cannot rely on counting them.


On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
I have a proposal that would allow each user to optionally configure the
maximum block weight at a support threshold.

It recognizes that there is no need for off chain bickering, by
providing a mechanism that lets each users freely choose their own
parameters while still maintaining full coordination of any changes.

The BIP can be found here:


It is worth noting that this proposal does neither gives more power to
miners nor reduces decentralization. Miners still rely on their blocks
being accepted by economic nodes to sell their minted coins. This
proposal doesn't change that.

Regards,
Tomas van der Wansem
bitcrust
_______________________________________________
bitcoin-dev mailing list

--_----------=_149561485024075403--