public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pindar Wong <pindar.wong@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Various block size proposals
Date: Sat, 13 Jun 2015 07:29:29 +0800	[thread overview]
Message-ID: <CAM7BtUrDc=Kx_QazKa7Mi4Qz0+Qz8YN0ozjs055zXkBh6KQsDw@mail.gmail.com> (raw)
In-Reply-To: <CABaSBaz8-eHzrkt4oGCrXmDamEhZmNp2GUX8oZ+8Xt1VZWMDxg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6892 bytes --]

Thanks Bryan for collating these links in one great list. This is very
helpful and thanks for sharing it.

Feel free to fork https://github.com/EthanHeilman/BlockSizeDebate
edit to add the list of proposals and create a pull request to Ethan.

There's also a miningconsensus.slack.com group to have discussion w.r.t.
fact/source checking, completeness  (e.g. from IRC) etc.

Tks.

p.


On Sat, Jun 13, 2015 at 3:13 AM, Bryan Bishop <kanzure@gmail.com> wrote:

> 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
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 14352 bytes --]

      reply	other threads:[~2015-06-12 23:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 19:13 [Bitcoin-development] Various block size proposals Bryan Bishop
2015-06-12 23:29 ` Pindar Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM7BtUrDc=Kx_QazKa7Mi4Qz0+Qz8YN0ozjs055zXkBh6KQsDw@mail.gmail.com' \
    --to=pindar.wong@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=kanzure@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox