public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Chris Priest <cp368202@ohiou.edu>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] *Changing* the blocksize limit
Date: Sat, 6 Aug 2016 18:52:55 +0000	[thread overview]
Message-ID: <201608061852.56738.luke@dashjr.org> (raw)
In-Reply-To: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>

This is exactly what segwit does...

On Saturday, August 06, 2016 2:15:22 PM Chris Priest via bitcoin-dev wrote:
> Because the blocksize limit is denominated in bytes, miners choose
> transactions to add to a block based on fee/byte ratio. This mean that
> if you make a transaction with a lot of inputs, your transaction will
> be very big, an you'll have a to pay a lot in fees to get that
> transaction included in a block.
> 
> For a long time I have been of the belief that it is a flaw in bitcoin
> that you have to pay more to move coins that are sent to you via small
> value UTXOs, compared to coins sent to you through a single high
> values UTXO. There are many legitimate uses of bitcoin where you get
> the money is very small increments (such as microtransactions). This
> is the basis for my "Wildcard inputs" proposal now known as BIP131.
> This BIP was rejected because it requires a database index, which
> people thought would make bitcoin not scale, which I think is complete
> malarkey, but it is what it is. It has recently occurred to me a way
> to achieve the same effect without needing the database index.
> 
> If the blocksize limit was denominated in outputs, miners would choose
> transactions based on maximum fee per output. This would essentially
> make it free to include an input to a transaction.
> 
> If the blocksize limit were removed and replaced with a "block output
> limit", it would have multiple positive effects. First off, like I
> said earlier, it would incentivize microtransactions. Secondly it
> would serve to decrease the UTXO set. As I described in the text of
> BIP131, as blocks fill up and fees rise, there is a "minimum
> profitability to include an input to a transaction" which increases.
> At the time I wrote BIP131, it was something like 2 cents: Any UTXO
> worth less than 2 cents was not economical to add to a transaction,
> and therefore likely to never be spent (unless blocks get bigger and
> fee's drop). This contributes to the "UTXO bloat problem" which a lot
> of people talk about being a big problem.
> 
> If the blocksize limit is to be changed to a block output limit, the
> number the limit is set to should be roughly the amount of outputs
> that are found in 1MB blocks today. This way, the change should be
> considered non-controversial. I think its silly that some people think
> its a good thing to keep usage restricted, but again, it is what it
> is.
> 
> Blocks can be bigger than 1MB, but the extra data in the block will
> not result in more people using bitcoin, but rather existing users
> spending inputs to decrease the UTXO set.
> 
> It would also bring about data that can be used to determine how to
> scale bitcoin in the future. For instance, we have *no idea* how the
> network will handle blocks bigger than 1MB, simply because the network
> has never seen blocks bigger than 1MB. People have set up private
> networks for testing bigger blocks, but thats not quite the same as
> 1MB+ blocks on the actual live network. This change will allow us to
> see what actually happens when bigger blocks gets published.
> 
> Why is this change a bad idea?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2016-08-06 18:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06 14:15 [bitcoin-dev] *Changing* the blocksize limit Chris Priest
2016-08-06 18:52 ` Luke Dashjr [this message]
2016-08-09  2:21 ` Peter Todd

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=201608061852.56738.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=cp368202@ohiou.edu \
    /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