summaryrefslogtreecommitdiff
path: root/d3/0ef6f636f0b6561fc17a0bbc5a0dfbb3a977b6
blob: 50e0e3e8d7edd0a1429d50c3f8a32055d36a7d5c (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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1C14D8A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 21:23:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB130128
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 21:23:19 +0000 (UTC)
Received: from mail-io0-f172.google.com ([209.85.223.172]) by
	mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
	0MXXjU-1ZLKb30pRW-00WS8T for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 23:23:19 +0200
Received: by iods203 with SMTP id s203so1242190iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 14:23:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.148.8 with SMTP id w8mr35633192iod.116.1439328198570;
	Tue, 11 Aug 2015 14:23:18 -0700 (PDT)
Received: by 10.50.104.198 with HTTP; Tue, 11 Aug 2015 14:23:18 -0700 (PDT)
In-Reply-To: <CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
	<CABm2gDoz4NMEQuQj6UHCYYCwihZrEC4Az8xDvTBwiZDf9eQ7-w@mail.gmail.com>
	<8181630.GdAj0CPZYc@coldstorage>
	<CABm2gDp2svO2G5bHs5AcjjN8dmP6P5nv0xriWez-pvzs2oBL5w@mail.gmail.com>
	<CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com>
	<CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com>
	<CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@mail.gmail.com>
	<CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
	<CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>
Date: Tue, 11 Aug 2015 22:23:18 +0100
Message-ID: <CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:xoyHQAqCL0Tac0GZfBPmeGav32N40pklsIbIZE1VM0yX/2iOrxP
	fSyWsSebQFsvbLcmKizmHZAbShNu643Cx1aIiYlh+ws65jMLDhjYZYDvM9f8oE29IJjRXsR
	/ckAlmkggWyO7/niT45By4n1P+CSGj/DanHhWC34W6jhlVBVnruI7mVzlgkJZHegUkKjCOV
	sj3H9ocs2wULQ9CCkOHbw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:DmvTbEb2F1o=:dDgqdcL2/7gOpIAw5EHGVH
	YB2xpc6B3HxyHz0WCoplSI9hIO6kWNsWJwqHl79EpyWjd0oq5Dv5T0d6O/r0mYZCkhZsuSZbN
	op6up7x82rzs/oHRk3C1XURGXwR3NuElXNRxk4O21yLgOY9hj8ubixOz7Z1c9/khmw5IJgHNu
	K+CSbaTn1Nl/1A4vMFmBBSyNjyCVo1AEHMJPefTp7AAbDryMj2z773bj8wmJi+L9NiHnWQDCO
	z0cwehbSTFE1cIWC/IjjFnF3xlngdrHAeMYABdFPd0yq59Am1ejFnzlOeym7L2HretBJWRiKO
	BNDWY2TuWrKt03NULVWJWcV+QczN2QzE0Bme6io+hCBTisVn1Xdp1dTf5MPMl4j97BDm7owzm
	WmUnlowX8GRxTRE3dTGRrO9p8uad+3yhTrpqtOLYvx0uTdqAn2D7Kl/GhONPyVrg2lOvKRW5R
	B6RvSF1h5kajrPSsp/nkOzBqMUgQNwnXEbdMsWHGdFSnTribymZsCkVe+c1xgpoM/xnOs2oCM
	NzES01l0/SlU+q9NWGSlEXsRoVmOq4ft1x3p0bchGWhYEj5d+fGvtJldExQrkFzCgJk0bKNR9
	xKs/xJfPg3MLYIKC4iF+i6MiWObjE9x5VAiUaPNSDN10BfL52HxD7fGCvae2Ge0fn+e6fxL7e
	xwbiN4zL/3bvPt+c7gGkz/++c8td7VU17PtR/yBQyvN17CPnWLgxFgyfaoD0kUhaO/nAjzasO
	rfiVkNNlBUTP2bxM
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 11 Aug 2015 21:23:21 -0000

I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin.  I think the interesting thing is trustlessness - being able
to transact without relying on third parties.

Adam


On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the only
> reason why we're all even here on this mailing list talking about this, is
> because Bitcoin is growing, since it's "better money than other money". One
> of the key characteristics toward that is Bitcoin being inexpensive to
> transact. If that characteristic is no longer true, then Bitcoin isn't going
> to grow, and in fact Bitcoin itself will be replaced by better money that is
> less expensive to transfer.
>
> So the importance of this issue cannot be overstated -- it's compete or die
> for Bitcoin -- because people want to transact with global consensus at high
> volume, and because technology exists to service that want, then it's going
> to be met. This is basic rules of demand and supply. I don't necessarily
> disagree with your position on only wanting to support uncontroversial
> commits, but I think it's important to get consensus on the criticality of
> the block size issue: do you agree, disagree, or not take a side, and why?
>
>
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>>
>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> Hitting the limit in and of itself is not necessarily a bad thing. The
>>> question at hand is whether we should constrain that limit below what
>>> technology is capable of delivering. I'm arguing that not only we should
>>> not, but that we could not even if we wanted to, since competition will
>>> deliver capacity for global consensus whether it's in Bitcoin or in some
>>> other product / fork.
>>
>>
>> The question is not what the technology can deliver. The question is what
>> price we're willing to pay for that. It is not a boolean "at this size,
>> things break, and below it, they work". A small constant factor increase
>> will unlikely break anything in the short term, but it will come with higher
>> centralization pressure of various forms. There is discussion about whether
>> these centralization pressures are significant, but citing that it's
>> artificially constrained under the limit is IMHO a misrepresentation. It is
>> constrained to aim for a certain balance between utility and risk, and
>> neither extreme is interesting, while possibly still "working".
>>
>> Consensus rules are what keeps the system together. You can't simply
>> switch to new rules on your own, because the rest of the system will end up
>> ignoring you. These rules are there for a reason. You and I may agree about
>> whether the 21M limit is necessary, and disagree about whether we need a
>> block size limit, but we should be extremely careful with change. My
>> position as Bitcoin Core developer is that we should merge consensus changes
>> only when they are uncontroversial. Even when you believe a more invasive
>> change is worth it, others may disagree, and the risk from disagreement is
>> likely larger than the effect of a small block size increase by itself: the
>> risk that suddenly every transaction can be spent twice (once on each side
>> of the fork), the very thing that the block chain was designed to prevent.
>>
>> My personal opinion is that we should aim to do a block size increase for
>> the right reasons. I don't think fear of rising fees or unreliability should
>> be an issue: if fees are being paid, it means someone is willing to pay
>> them. If people are doing transactions despite being unreliable, there must
>> be a use for them. That may mean that some use cases don't fit anymore, but
>> that is already the case.
>>
>> --
>> Pieter
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>