summaryrefslogtreecommitdiff
path: root/1b/e6b48f407ac7dfee1e535d6deb4f62cefa28d6
blob: 29726730edfd7a3104183178c1c9982734ad3369 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CF4771
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Aug 2016 18:53:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (unknown [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 95A0F137
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Aug 2016 18:53:16 +0000 (UTC)
Received: from ishibashi.localnet (adsl-98-70-231-167.gnv.bellsouth.net
	[98.70.231.167]) (Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 4745338A17C7;
	Sat,  6 Aug 2016 18:52:58 +0000 (UTC)
X-Hashcash: 1:25:160806:cp368202@ohiou.edu::k+/oa4=kd80J2V1v:aA3KE
X-Hashcash: 1:25:160806:bitcoin-dev@lists.linuxfoundation.org::6DyRP00W6RC206hT:apSq5
From: Luke Dashjr <luke@dashjr.org>
To: Chris Priest <cp368202@ohiou.edu>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 6 Aug 2016 18:52:55 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; )
References: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
In-Reply-To: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201608061852.56738.luke@dashjr.org>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC
	autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] *Changing* the blocksize limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2016 18:53:17 -0000

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