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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 950CC48B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:51:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7937E9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:51:12 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so4365781wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 10:51:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=Jx7qooPuQFUcVoxzsse+AuPjvP1DRP4XEXtyZ6ofKI4=;
b=gqfqrRZrLsECht1T5TagQGO+mOFjCP0MSaSjTvf+2enNcE9BJ3fh81wJ5upXqtesPv
9XNSy5q1fMNVM5OL6K5SgTqoz+uUDZ05DC1dDQkBSs5Ga4tarSyYQmBdsj0R4gtAsVDx
uUbKw/vzBvPBZabGrQaJfhPd2+joLrI8A71iHRWzK5Ay/hX8G5cTCUi6X/GY6Kw/HnsQ
iD+2hZnbjV7EGCp4jBSLCHBWajq9IrVamptDg8lKy4VYPNuWt0RCJ6cPSW4SIPBp4Z4I
RVDYNbtlSs6x51+UXxSVr5msxgoIyxX83r8iBMjOny+bmH4rOXq3eMUCuyX7HdUlTP0y
JIVA==
X-Gm-Message-State: ALoCoQnhZqgfBdeMCtjJlwCqY2WSlwgACqVCHPnNMTkXcYO7JhoXXg4qn8O73QX04uRBPaqtKydP
MIME-Version: 1.0
X-Received: by 10.180.109.6 with SMTP id ho6mr55504271wib.58.1437673871591;
Thu, 23 Jul 2015 10:51:11 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 10:51:11 -0700 (PDT)
In-Reply-To: <55B113AF.40500@thinlink.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
<55B113AF.40500@thinlink.com>
Date: Thu, 23 Jul 2015 19:51:11 +0200
Message-ID: <CABm2gDp5-D3r=0rbq28-h8ewyHY8Rj9B0AFjO1fWfyuUEDMMfg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tom Harding <tomh@thinlink.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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: Thu, 23 Jul 2015 17:51:13 -0000
On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 7/23/2015 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev wrote:
>
>> If the user expectation is that a price would never arise because
>> supply is going to be increased ad infinitum and they will always be
>> able to send fast in-chain bitcoin transactions for free, just like
>> breath air (an abundant resource) for free, then we should change that
>> expectation as soon as possible.
>
> No. We should accept that reality may change, and we should promote
> understanding of that fact.
>
> We should not artificially manipulate the market "as soon as possible,"
> since we ourselves don't know much at all about how the market will
> unfold in the future.
We know perfectly well that the system will need to eventually be
sustained by fees.
We should stop misinforming new users talking them about how bitcoin
transactions "are free", because they're clearly not.
>> the criteria for the consensus block size should be purely based on
>> technological capacity (propagation benchmarking, etc) and
>> centralization concerns
>
> Right, purely these. There is no place for artificially manipulating
> expectations.
Am I "artificially manipulating expectations" ?
>> they will simply advance the front and start another battle, because
>> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
>> Mike, show me that I'm wrong on this point. Please, answer my question
>> this time. If "not now", then when?
>
> Bitcoin has all the hash power. The merkle root has effectively
> infinite capacity. We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
Timestamping data using the blockchain is not the same as including
that the data in the blockchain itself because the later is a scarce
resource.
The "timestamping space" is already unlimited today with no changes.
You can use a bitcoin transaction to timestamp an unbounded amount of
external data using exactly 0 extra bytes in your transaction!
Here's the code: https://github.com/Blockstream/contracthashtool
And I'm very interested in scaling Bitcoin, I just disagree that
changing a constant is a "scaling solution".
On Thu, Jul 23, 2015 at 6:28 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev
>> We haven't tried yet. I can't answer for the people you asked, but
>> personally I haven't thought much about when we should declare failure.
>
>
> Yes! Lets plan for success!
I extremely disagree that having a block limit is failure. It's a
design decision to protect the system against centralization (which we
will be able to rise as we solve technical and centralization problems
we have today).
But thank you for being more clear about it now, Gavin. You won't stop
on a 8GB or 32GB limit because you think having ANY limit would be a
failure.
Is that correct?
If not, can you please answer clearly when and why you think the
blocksize should be lower than demand (when you will be ok with
bitcoin users having to pay fees for the service they're enjoying)?
If your answer is "never", I would prefer to hear it from you than
just concluding it by the lack of an answer.
|
