From: Bryan Bishop <kanzure@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Bryan Bishop <kanzure@gmail.com>
Subject: [Bitcoin-development] Various block size proposals
Date: Fri, 12 Jun 2015 14:13:35 -0500 [thread overview]
Message-ID: <CABaSBaz8-eHzrkt4oGCrXmDamEhZmNp2GUX8oZ+8Xt1VZWMDxg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5854 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 12033 bytes --]
next reply other threads:[~2015-06-12 19:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 19:13 Bryan Bishop [this message]
2015-06-12 23:29 ` [Bitcoin-development] Various block size proposals Pindar Wong
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=CABaSBaz8-eHzrkt4oGCrXmDamEhZmNp2GUX8oZ+8Xt1VZWMDxg@mail.gmail.com \
--to=kanzure@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/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