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
|
Return-Path: <bdimych@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1568984
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2015 14:04:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com
[209.85.214.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A458F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2015 14:04:28 +0000 (UTC)
Received: by obbhe7 with SMTP id he7so93359808obb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2015 07:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
bh=sKia8oo+W/vd8ebxCIPY8dEcaWNJES6pGW72lW8j59I=;
b=kJnBtJXwcPj66DsywgtvkB0DQfWPxo/hrPXu47ENlF7TAqbPA4ymkBCU7vTqAR+Lp9
eNlTlWtXsMCYJWDUG4PGb2JMlM7f98e3wogmmwPG9nQ56JMGpARuKBLh+WBuHTuiu53x
39CX8MdunEIXt160qmtAlMpEY7/RjSS1MzV7WqmT2WhMF6KjtOR9NcTWK4qjQ5HXtaOg
39stJQD+GNDLhWGlbohaEqFyE4QA3s9c0l81ixJu9rOL1YDm/kquEIQv31Yy/1DWSgAg
519f8cg+qmiIXqW0bsySlFSJda4sboQ17oMBqPIipz0nUKUZYOCLhPHbkX85cobhGjjd
5HNw==
MIME-Version: 1.0
X-Received: by 10.182.76.1 with SMTP id g1mr17583641obw.2.1440338667854; Sun,
23 Aug 2015 07:04:27 -0700 (PDT)
Received: by 10.202.225.214 with HTTP; Sun, 23 Aug 2015 07:04:27 -0700 (PDT)
In-Reply-To: <CABm2gDp2TONJxSVSdS7bq-WAXNVfQGZiKyhx2haerA3WkoaNxQ@mail.gmail.com>
References: <CALNn0ZZ5gY6R7gzpLpbNnFecAz35ZqaLx_RNPxx=SoJTAdHDXg@mail.gmail.com>
<CABm2gDp2TONJxSVSdS7bq-WAXNVfQGZiKyhx2haerA3WkoaNxQ@mail.gmail.com>
Date: Sun, 23 Aug 2015 09:04:27 -0500
Message-ID: <CALNn0ZYDw+f1j+7PydnAaDqx+sP93EAxQDccisM1+R2UJc7Pog@mail.gmail.com>
From: Bdimych Bdimych <bdimych@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,URIBL_BLACK
autolearn=no 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] Block size possible solution - to set minimum size
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: Sun, 23 Aug 2015 14:04:29 -0000
I apologize, I'm not familiar with technical details, may be stupid,
only general thoughts:
-overlapped block sizes - two blockchains, uncertainty, unpredictable
results, trust gets down
-non-overlapped - single blockchain, determined growing, everybody
knows the schedule what and when will happen
---
You wrote "cheated",
but why?
If it will be possible to fill with zeroes
[transactions]+[zeroes]
or
[transactions]+[miner's dummy transactions]
why the second variant will be better for miner?
and why it will be not good for other users?
With Best Regards
Dmitry Bolshakov
bdimych@gmail.com
On Sun, Aug 23, 2015 at 1:40 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> A minimum block size does nothing to prevent the problems that come
> from schism hardforks.
> But also a minimum block size can be trivially cheated as recently
> explained on this list:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01031=
7.html
>
> "[...] miners can just pay to themselves to follow the minimum size
> block rule without risking anything.
> As long as they have a single matured satoshi they can just pay to
> themselves with it as many times as they need in the same block."
>
> It is good to search previous post before proposing or asking
> something (it could have been proposed/asked earlier):
>
> http://www.catb.org/esr/faqs/smart-questions.html
>
>
> On Sun, Aug 23, 2015 at 1:30 AM, Bdimych Bdimych via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Hi,
>> As I understand the main problem of the fork Core<->XT is possibility
>> of double spending:
>> -I run XT and spend my coins
>> -it is written in 8mb block
>> -Core does not accept this block
>> -I run Core and spend my coins again
>> -it is written in 1mb block
>> -but XT accepts this block too
>> so
>> -in the XT blockchain both blocks [8] and [1] contain my coins
>>
>> I thought that possible solution can be to set minimum block size
>> i.e.
>> 2016: 1mb <=3D blockSize < 2mb
>> 2017: 2mb <=3D blockSize < 3mb
>> 2018: 3mb <=3D blockSize < 4mb
>> etc
>>
>> Free space could be filled with zeroes and compressed.
>>
>> That's all, just an idea.
>>
>>
>> With Best Regards
>> Dmitry Bolshakov
>> bdimych@gmail.com
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
