Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3UOe-0007Kr-Hg for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 19:13:44 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=kanzure@gmail.com; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3UOc-0006yq-9k for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 19:13:44 +0000 Received: by lacny3 with SMTP id ny3so6504235lac.3 for ; Fri, 12 Jun 2015 12:13:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.23.234 with SMTP id p10mr16469934laf.52.1434136415845; Fri, 12 Jun 2015 12:13:35 -0700 (PDT) Received: by 10.152.18.168 with HTTP; Fri, 12 Jun 2015 12:13:35 -0700 (PDT) Date: Fri, 12 Jun 2015 14:13:35 -0500 Message-ID: From: Bryan Bishop To: Bitcoin Development , Bryan Bishop Content-Type: multipart/alternative; boundary=089e0160bbeca047fa051856e7a4 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kanzure[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z3UOc-0006yq-9k Subject: [Bitcoin-development] Various block size proposals X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:13:44 -0000 --089e0160bbeca047fa051856e7a4 Content-Type: text/plain; charset=UTF-8 Here are some proposals regarding the minimum block size questions, as well as other related scalability issues. Dynamic block size limit controller (maaku) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html https://www.reddit.com/r/Bitcoin/comments/35c47x/a_proposal_to_expand_the_block_size/ Re: dynamic block size limit controller (gmaxwell) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html Various other gmaxwell-relayed ideas http://www.reddit.com/r/Bitcoin/comments/37pv74/gavin_andresen_moves_ahead_with_push_for_bigger/crp2735 Increasing the max block size using a soft-fork (Tier Nolan) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Elastic block cap with rollover penalties (Meni Rosenfield) https://bitcointalk.org/index.php?topic=1078521 worked example https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115 section 6.2.3 of https://cryptonote.org/whitepaper.pdf rollover transaction fees https://bitcointalk.org/index.php?topic=80387.0 Variable mining effort (gmaxwell) http://sourceforge.net/p/bitcoin/mailman/message/34100485/ BIP100 Soft-fork limit of 2 MB (jgarzik) http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Transaction fee targeting https://bitcointalk.org/index.php?topic=176684.msg9416723#msg9416723 Difficulty target scaling https://www.reddit.com/r/Bitcoin/comments/38937n/idea_make_the_difficulty_target_scale_with_block/ Annual 50% max block size increase https://www.reddit.com/r/Bitcoin/comments/351dft/what_about_gavins_2014_proposal_of_having_block/ Various algorithmic adjustment proposals https://bitcointalk.org/index.php?topic=1865.0 https://www.reddit.com/r/Bitcoin/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/ccwd7xh https://www.reddit.com/r/Bitcoin/comments/35azxk/screw_the_hard_limit_lets_change_the_block_size/ https://www.reddit.com/r/Bitcoin/comments/359y0i/quick_question_about_the_block_size_limit_issue/ http://www.reddit.com/r/Bitcoin/comments/385xqj/what_if_block_size_limits_were_set_to_increase/ http://www.age-of-bitcoin.com/dynamic-block-size-cap-scaling/ (against) http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html Average over last 144 blocks http://www.reddit.com/r/Bitcoin/comments/38fmra/max_block_size_2_average_size_of_last_144_blocks/ Extension blocks (Adam Back) (why would he burn this idea for something so trivial?) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08005.html http://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ http://www.reddit.com/r/Bitcoin/comments/39hgzc/blockstream_cofounder_president_adam_back_phd_on/cs3tgss Voting by paying to an address (note: vote censorship makes this impractical, among other reasons) http://www.reddit.com/r/Bitcoin/comments/3863vw/a_brandnew_idea_for_resolving_the_blocksize_debate/ http://www.reddit.com/r/Bitcoin/comments/1g0ywj/proposal_we_should_vote_on_the_blocksize_limit/ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02325.html Vote by paying fees https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08164.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html Double the max block size at each block reward halving https://www.reddit.com/r/Bitcoin/comments/359jdc/just_double_the_max_blocksize_on_every_block/ Reducing the block rate instead of increasing the maximum block size (Sergio Lerner) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html https://www.reddit.com/r/Bitcoin/comments/35kpgk/sergio_lerner_on_bitcoindevelopment_reducing_the/ Decrease block interval https://www.reddit.com/r/Bitcoin/comments/2vefmp/please_eli5_besides_increasing_the_block_size_why/ https://www.reddit.com/r/Bitcoin/comments/35hpkt/please_remind_me_once_again_why_we_cant_decrease/ Increase default soft block size limit in Bitcoin Core http://www.reddit.com/r/Bitcoin/comments/38i6qr/why_not_increase_the_default_block_size_limit/ https://github.com/bitcoin/bitcoin/pull/6231 Consider the size of the utxo set when determining max block size (note that utxo depth cannot have consensus) https://bitcointalk.org/index.php?topic=153401.20 Reduce and decrease the max block size https://www.reddit.com/r/Bitcoin/comments/381ygv/who_is_in_favour_of_reducing_the_blocksize_limit/ https://www.reddit.com/r/Bitcoin/comments/2vedt4/better_we_make_block_size_50kb_and_test/ Change the value of MAX_BLOCK_SIZE in Bitcoin Core https://bitcointalk.org/index.php?topic=140233.0 Problems with floating block size limits (petertodd) https://bitcointalk.org/index.php?topic=144895.0 Develop other ways to support high transaction volumes (gavinandresen) https://bitcointalk.org/index.php?topic=96097.msg1059475#msg1059475 Simplified payment verification https://bitcoin.org/bitcoin.pdf Lightning network https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf GHOST https://eprint.iacr.org/2013/881.pdf Payment channels https://bitcoinj.github.io/working-with-micropayments Tree chains http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html https://github.com/petertodd/tree-chains-paper fedpeg + SPV https://github.com/ElementsProject/elements/blob/7848ae0eed5506fb32872b6d74a12fd781aa3024/contrib/fedpeg/rotating_consensus.py Known missing: - old bitcoin-development proposals - old bitcointalk proposals - anything unique from IRC On a related note, the other day I found that reading all of the -wizards logs regarding sidechains only takes 2 hours. So... that's something. YMMV. - Bryan http://heybryan.org/ 1 512 203 0507 --089e0160bbeca047fa051856e7a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are some proposals regarding the minimum block s= ize questions, as well as other related scalability issues.

<= /div>
Dynamic block size limit controller (maaku)


V= arious other gmaxwell-relayed ideas

Incre= asing the max block size using a soft-fork (Tier Nolan)

Elastic block cap wit= h rollover penalties (Meni Rosenfield)

Variable mining effort (g= maxwell)

<= div>http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf<= /div>

Transaction fee targeting
<= div>
Difficulty target scaling

Annual= 50% max block size increase

Various algorithmic adju= stment proposals
https://www.reddit.com/r/Bitco= in/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/ccwd7x= h
(against) http://garzikrants.blogspot.com/2013/02/bitcoin-bloc= k-size-thoughts.html

Average over last 144 blo= cks

Extension blocks (Adam Back) (why would he burn t= his idea for something so trivial?)

=
Voting by paying to an address (note: vote censorship makes this impra= ctical, among other reasons)
<= div>
Vote by paying fees

Double the max block size at each block reward halving

Reducing the block rate instead of increasing the maximum block size (Ser= gio Lerner)
Consider the size of the utxo set when determining max bl= ock size (note that utxo depth cannot have consensus)

Reduce and decre= ase the max block size


Know= n missing:
- old bitcoin-development proposals
- old bi= tcointalk proposals
- anything unique from IRC

On a related note, the other day I found that reading all of the -wi= zards logs regarding sidechains only takes 2 hours. So... that's someth= ing. YMMV.

- Bryan
http://heybryan.org/1 512 203 0507
--089e0160bbeca047fa051856e7a4--