<oembed><type>rich</type><version>1.0</version><author_name>npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87</author_name><author_url>https://nostr.ae/npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-13&#xA;📝 Original message:Please forgive my ignorance, but why should Bitcoin users have a say in&#xA;block size limits?  It&#39;s the miners and Bitcoin node operators that bear&#xA;the burden of managing large blocks, no?&#xA;&#xA;Users voting on network parameters sounds like neighbors voting on how deep&#xA;my swimming pool should be.&#xA;&#xA;Thanks,&#xA;-Danny&#xA;&#xA;On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd &lt;pete at petertodd.org&gt; wrote:&#xA;&#xA;&gt; Jeff Garzik recently proposed that the upper blocksize limit be removed&#xA;&gt; entirely, with a &#34;soft&#34; limit being enforced via miner vote, recorded by&#xA;&gt; hashing power.&#xA;&gt;&#xA;&gt; This mechanism within the protocol for users to have any influence over&#xA;&gt; the miner vote. We can add that back by providing a way for transactions&#xA;&gt; themselves to set a flag determining whether or not they can be included&#xA;&gt; in a block casting a specific vote.&#xA;&gt;&#xA;&gt; We can simplify Garzik&#39;s vote to say that one of the nVersion bits&#xA;&gt; either votes for the blocksize to be increased, or decreased, by some&#xA;&gt; fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a&#xA;&gt; nVersion bit in transactions themselves, also voting for an increase or&#xA;&gt; decrease. Transactions may only be included in blocks with an&#xA;&gt; indentical vote, thus providing miners with a monetary incentive via&#xA;&gt; fees to vote according to user wishes.&#xA;&gt;&#xA;&gt; Of course, to cast a &#34;don&#39;t care&#34; vote we can either define an&#xA;&gt; additional bit, or sign the transaction with both versions. Equally we&#xA;&gt; can even have different versions with different fees, broadcast via a&#xA;&gt; mechanism such as replace-by-fee.&#xA;&gt;&#xA;&gt;&#xA;&gt; See also John Dillon&#39;s proposal for proof-of-stake blocksize voting:&#xA;&gt;&#xA;&gt;&#xA;&gt; https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html&#xA;&gt;&#xA;&gt; --&#xA;&gt; &#39;peter&#39;[:-1]@petertodd.org&#xA;&gt; 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778&#xA;&gt;&#xA;&gt;&#xA;&gt; ------------------------------------------------------------------------------&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; Bitcoin-development mailing list&#xA;&gt; Bitcoin-development at lists.sourceforge.net&#xA;&gt; https://lists.sourceforge.net/lists/listinfo/bitcoin-development&#xA;&gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/da34f3e3/attachment.html&gt;</html></oembed>