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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 73139B6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Nov 2019 13:52:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E28F8D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Nov 2019 13:52:57 +0000 (UTC)
Date: Mon, 11 Nov 2019 13:52:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1573480374;
bh=5xsSM+DaNYzPN35ssVgCqlM6Wx2fRRB1FFBTbZfHBtY=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=OcptXCucxwKWUhYURDMliR4FYetZJH8G/QIvURkm/qX2yzxiMi1sjSKUOAiqviEQe
peuvR+stWQjAb/dWxGu/qKNPy1UqtzfIF0sHYmHxErFMUxMWUn+kXC7YEwrutYNAnb
rOPH9ESUBEUS6uCPEUcRsvRBYvdR+SGnQXIwaL+Q=
To: Trevor Groves <gurvy51@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <P-TJrrShiuEPOOWqGpb2iLL9reReXD_IYPzSM5hB_brQfQORYgo-ALqTTf6aKAqUQimcFU-tpYBVQBlgkRDscJ3OxM43Z-LEsctoaD-gjIk=@protonmail.com>
In-Reply-To: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
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
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
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: Mon, 11 Nov 2019 13:52:58 -0000
Several days late, I would like to add my NACK here.
* The actual fees paid to miners are not in fact known.
Miners may accept side fees that are not explicitly visible on the block,=
and miners may pad their blocks with faked self-paying transactions.
Further, such side fees and faked transactions do not modify the economic=
assumptions of Bitcoin.
* Mining fees are simply an anonymity technique: what is material economi=
cally is that miners are paid for confirming transactions, thus side fees a=
re perfectly fine when considering economic incentives of Bitcoin mining.
* Without this proposed mechanism, padding blocks with faked self-paying =
transactions is self-destructive behavior for miners, as the transaction ta=
kes up space that cannot be used for actually-paying transactions.
* However, by computing only using the explicit fees on the block (and no=
t the actual fees that miners actually get), various additional games can b=
e played by miners.
Such games make considering the overall security of mining much harder =
and we may end up with worse security due to misaligned incentives, includi=
ng encouraging miners to pad blocks with faked transactions (which otherwis=
e is discouraged by the current protocol).
* Scaling means getting more impact for less resource consumption.
***All*** block size increases are getting more impact for ***more*** res=
ource consumption, thus not scaling.
> Dynamic MaxBlockSize =C2=A0- 3 Byte Solution
> "DMBS"
>
> If
> (Last TOTAL Block Trans fees)=C2=A0 > =C2=A0(AVG (Last 100 Blocks Trans F=
ees))
> AND
> current MaxBlockSize =C2=A0=3D> 0.99 MB =C2=A0
> AND
> MaxBlockSize has not changed in 10 Blocks
> ** see error catch below
> Then =C2=A0
> ON (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlock=
Size x 1.1)
> ELSE =C2=A0
> AT (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlock=
Size =C2=A0/ 1.1)
> ELSEIF
> (current MaxBlockSize =C2=A0=3D< 0.99 =C2=A0or current MaxBlockSize > 655=
3.5 MB)
> Null (no action taken)
> **where 9 above represents the ActivateONBlock (software side) Variable
> =C2=A0-------------
> We add this 3 Byte Variable Factor to the white space in the Current Bloc=
k.
>
> eg. =C2=A0this 3 byte HEX=C2=A0 =C2=A0 19000A
> the first bit "1" =C2=A0can be 1,2 or 0 =C2=A0 =C2=A0
> 1 =C2=A0=3D =C2=A0increase future block (9 blocks ahead)
> 2 =C2=A0decrease future block =C2=A0(9 blocks ahead)
> 0 =C2=A0 =C2=A0No Action (rules evaluate to null)
> **where 9 above represents the ActivateONBlock (software side) Variable
> --------------
> The Second bit is a Global Variable "9" represents a countdown to the set=
value action, placed to synchronize network forward =C2=A0changes in "x" b=
locks. software lowers value if evaluates to True a second time=C2=A0 and s=
o on.=C2=A0
> ("Count down" if you will)
> the last 2 bytes represent =C2=A0the globally accepted "MaxBlockSize" Var=
iable, and is distributed within each block moving forward in this rightmos=
t (2 byte) factor.=C2=A0 In this case above,
> The variable portion =C2=A0"000A" (32 Bit value) represents decimal value=
10 being 1.0 MB block.
> the decimal place is Always Assumed, and must be hard coded
> Because this presents a =C2=A0theoretical =C2=A0Max limit of "FFFF" =
=C2=A0or 6553.5 MB, We would
> have to add a last rule "only as a error catch"
> =C2=A0** AND IF MaxBlockSize < 6553.5
> ---
> Increasing and decreasing
> On Every Block mined or distributed, the software can run the above rule =
set, Change the Variable and Distribute the next block " In Synchronized fa=
shion". The above rules when combined evaluate to a YES or NO, This transla=
tes to a market reflection of increased system pressure or decreased market=
pressure. =C2=A0 I think we can agree, at peak periods the system chokes i=
tself off with fees and this is always only temporarily.=C2=A0 So we can ha=
ve the block, analyse system demand dynamically, and adjust on a globally a=
greed rule dynamically by market driven demand.
> Considering the ruleset above also Decreases =C2=A0the Block ONLY if its =
greater than 0.99mb this brings size back to a competitive state /and size =
once market demand pressures subside, yet achieves the smallest market feas=
ible block size while also maintaining all current rule sets.
> =C2=A0An attacker would have to affect all block fees over the last 16 ho=
urs worth of transactions to affect a 10% max block size increase but then =
only after waiting 1.5 hours, so long as nothing has changed in the last 1.=
5 hours and only for a limited amount of time. This approach also limits bl=
oat. This safety block window of 9 blocks provides a look forward and look =
behind value, in turn provides the network time to synchronize.
> 10 block sync window.=C2=A0 This, by design, also limits changes to one c=
hange=C2=A0 every 3 hours (20 blocks), if there is a market pressure "STATE=
" occurring.
> My Question to the community is. Will our current Block accommodate the 3=
Byte
> Variable, Is solving the Scaling issue worth using the 3 Bytes of space? =
=C2=A0
> I believe it is. =C2=A0
> --
> Software, =C2=A0Will need =C2=A0to Evaluate MaxBlockSize Variable, and Ac=
tivateONBlock Variable from the most recent distributed blocks DMBS =C2=
=A03 byte value.
> Run the rules , get the answer set the now known MaxBlockSize Var and Pro=
pegate the "DMBS" value.
>
> As capacity limits are breached, I think the majority agree "we need to a=
gree". =C2=A0
>
> MaxBlockSize would provide a suitable middle ground and address concerns =
in a dynamic fashion, without compromising =C2=A0or changing =C2=A0existing=
security.=C2=A0 =C2=A0
> =C2=A0Examples reflected in the blockchain 19000A=C2=A0 =C2=A0rules has e=
valuates to=C2=A0 true, increase expected in 9 blocks.1.0mb increases to 1.=
1mb
> if true for 9 more blocks=C2=A0 MaxBlockSize Var becomes=C2=A0 18000A.. 1=
7000A..,16000A ..and so on if=C2=A0 still true at 10000A var written become=
s=C2=A0
> 00000B when read from left to right,=C2=A0 0-no change, in 0 blocks curre=
nt " DMBS" value 000B or 1.1MB=C2=A0 and stays that way=C2=A0 00000B until =
MaxBlockSize=C2=A0 evaluates to "True" under a market pressure/ relief situ=
ation.=C2=A0
> I hope this makes sense, I would appreciate some feedback.=C2=A0
> TG
|
