44529d394cd487e0512aa40dd4880b9efde4a1
1 Return-Path: <n210241048576@gmail.com> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id BF3BDA7F 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Sat, 16 Jan 2016 18:20:14 +0000 (UTC) 7 X-Greylist: whitelisted by SQLgrey-1.7.6 8 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com 9 [209.85.223.169]) 10 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 92C7914B 11 for <bitcoin-dev@lists.linuxfoundation.org>; 12 Sat, 16 Jan 2016 18:20:13 +0000 (UTC) 13 Received: by mail-io0-f169.google.com with SMTP id q21so516028375iod.0 14 for <bitcoin-dev@lists.linuxfoundation.org>; 15 Sat, 16 Jan 2016 10:20:13 -0800 (PST) 16 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 17 h=mime-version:date:message-id:subject:from:to:content-type; 18 bh=Z9Irepp7PoRNYP7U5u9Ryv+WX5L2hjdpduNXf2Z+QTk=; 19 b=G9mO1KYksZkGoDoehCj9R6a5QDdQICrXEhLIxuF9X723bijcRlUTELsNOl1GI3pDeR 20 N4pLTJKKtv5bSuM3GUaD7CeIN78TGlSoXtO9M/Qcn2UmaWxuBmjtr3AnxoZZHCtMf7h7 21 LNAHO0ccub+4byu0KS/Y1nvfeapAEUTkt/Srcii/mlJXHbblhKOOkX5eXBj/nHs0gK26 22 xlTZHW628YXVJuVUtrOF4VIpb5RdvO5cGHMaKnyoMT9HeMaqFhl81JdcFla89TQtUXJo 23 mPmyTg3byKCZFsXKK+/KiR/RYJxyb98aUjI2GDKjJadxl1ZKAwsj/0plwuH2s3mOB1tg 24 rIww== 25 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 26 d=1e100.net; s=20130820; 27 h=x-gm-message-state:mime-version:date:message-id:subject:from:to 28 :content-type; 29 bh=Z9Irepp7PoRNYP7U5u9Ryv+WX5L2hjdpduNXf2Z+QTk=; 30 b=ZSjv6/olcWMKGvXZvXnN2S1ubXqCy3aTpGz6yVrueJJyxrNDVKATydVsPCPom6G6VP 31 KAOVtiCHUtx9iXPp6qmyCyImzbvUMvyysqEq/5WiJ0xgfDL9IooGFItNrr6wB1NE2v6Z 32 sbYI9ls8/bz8VP9YSNYYg5Nvah2RHwIV4GSBwZDwvX3dhwHGVcjNMSrITo2tvimYzo0l 33 HZZlpVNN0Wuigc2+ZWrQib6eFpnvDiYtL5jPTPOiHXZ7BQ0spuEI0AAqftYQxCuzmUq9 34 d/KMghPHrYMMUiyyDDsR5rbvEW+f/vBr6qMwgEz+NXNeeyKR+Gs/qKNb4VNxxwmIW1jC 35 nnkA== 36 X-Gm-Message-State: ALoCoQkOkV7w19LEM+LUm3JDdVd1mgSymRyOtknF4MnL95DLxO54ySE7U8z2mi7xXZ3XgPwotLKYKqG6FUytrzw6/lCEc6t47w== 37 MIME-Version: 1.0 38 X-Received: by 10.107.157.83 with SMTP id g80mr15403177ioe.187.1452968413099; 39 Sat, 16 Jan 2016 10:20:13 -0800 (PST) 40 Received: by 10.36.108.74 with HTTP; Sat, 16 Jan 2016 10:20:13 -0800 (PST) 41 Date: Sat, 16 Jan 2016 10:20:13 -0800 42 Message-ID: <CALJjGitKqSPOCC32-HiVG+s159Gn4dLm+7v=60zoqr2_my21Pg@mail.gmail.com> 43 From: Robert Grosse <n210241048576@gmail.com> 44 To: bitcoin-dev@lists.linuxfoundation.org 45 Content-Type: multipart/alternative; boundary=001a11407aac2200b10529779250 46 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, 47 DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 48 FROM_LOCAL_DIGITS, FROM_LOCAL_HEX, HTML_MESSAGE, 49 RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 50 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 51 smtp1.linux-foundation.org 52 X-Mailman-Approved-At: Mon, 18 Jan 2016 06:05:05 +0000 53 Subject: [bitcoin-dev] [BIP Draft] A modest proposal to increase maximum 54 transactions per block without requiring a hardfork 55 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 56 X-Mailman-Version: 2.1.12 57 Precedence: list 58 List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> 59 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 60 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 61 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 62 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 63 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 64 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 65 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 66 X-List-Received-Date: Sat, 16 Jan 2016 18:20:14 -0000 67 68 --001a11407aac2200b10529779250 69 Content-Type: text/plain; charset=UTF-8 70 71 Summary: This describes a new transaction format which allows most 72 transactions to take up less space (and thus fit more per block) and a 73 method to implement it requiring only a (non generalized) softfork. 74 75 = Compressed transactions = 76 This format is designed to allow the majority of transactions to take up 77 less space, by removing flexibility and unnecessary data. The requirements 78 to use a compressed transaction are 79 80 * Non-coinbase 81 * 1-8 inputs and 1-8 outputs 82 * Pay to pubkey hash only 83 84 Transactions which want to use arbitrary scripts or a larger number of 85 inputs and outputs can still use the existing transaction format. 86 87 A compressed transaction consists of 88 header byte, compressed inputs, compressed outputs, optional lock_time 89 90 header byte has the following format 91 * bit 7: Always 1, to make it easy to distinguish compressed and 92 uncompressed transactions 93 * bit 6: 1 if lock_time is used, otherwise 0 94 * bit 5-3: Number of inputs - 1 95 * bit 2-0: Number of outputs - 1 96 97 This saves 5+ bytes from omitting the version number and the input and 98 output count fields. Additionally, most transactions will not have 99 lock_time, saving another 4 bytes. 100 101 Compressed input: 102 previous transaction hash, index byte, signature, pubkey, optional 103 sequence_no 104 105 This has the following differences from a normal input: Index is only 1 106 byte, since it is at most 8 anyway. The top bit of the index byte indicates 107 whether the input has a sequence number. ScriptSig length is completely 108 omitted, and signature and public key are included directly, saving space 109 from the data push and check opcodes. And as before, sequence_no is 110 optional and usually omitted. 111 112 Compressed output: 113 compressed value (1-7 bytes), pubkeyhash 114 115 compressed value format: The high 3 bits of the first byte give the number 116 of following bytes. The lower 5 bits and the n following bytes comprise the 117 output value. The maximum possible value is 2099999997690000 satoshis, 118 which requires 7 bytes to encode, but most values will be far shorter. For 119 example, a value of 0.01 BTC could be encoded in just 3 bytes, saving 5. 120 121 As before the script length field is completely omitted, and the pubkeyhash 122 is included directly, without extra opcodes. 123 124 125 = Consensus = 126 127 Like all softforks, adoption by a minority of miners would cause problems. 128 Therefore, these changes would only take effect after a consensus. Miners 129 can advertise support for the new format by increment the version code. 130 Once X% of Y consecutive blocks have this version, the new changes take 131 effect. Users who do not upgrade will still work but will not always see 132 accurate balances in other addresses and miners who do not upgrade risk 133 mining an invalid block, encouraging them to upgrade. 134 135 = The Shadow Chain = 136 137 Now for the interesting part: Implementing the new format with only a 138 softfork. In order to qualify as a softfork, every valid block under the 139 new rules also has to be valid under the old rules. 140 141 Among other things this means that compressed transactions can't just be 142 included in place of an ordinary transaction in a block, since the legacy 143 (non-upgraded) clients will consider that invalid. Instead, they will be 144 hidden as extra data inside the coinbase transaction, which is allowed to 145 contain arbitrary data. 146 147 Additionally, in order to support interoperability between compressed and 148 uncompressed transactions, uncompressed transactions can hide compressed 149 inputs and ouputs inside of the normal inputs and outputs using a currently 150 unused opcode (OP_NOP1, hereafter referred to as OP_SHADOW). OP_SHADOW 151 isn't a script operation per se; instead it marked scripts that should be 152 interpreted differently under the new rules. 153 154 155 In the following, shadow input/output refers to a compressed input/output, 156 which is hidden as metadata and hence not visible to legacy clients. 157 158 The blockchain must also still be valid when all the hidden data is 159 ignored. When moving money from the visible to the shadow chain, there is 160 no problem, but when moving money back, things get trickier, since the 161 legacy client won't know about any of the shadow transactions. Therefore, 162 when sending money to the shadow chain, the transaction includes a 163 specially marked anyone-can-spend output. When moving money back from the 164 shadow chain, the transaction "spends" any available such outputs. 165 166 Since an arbitrary amount of splitting and combining can occur inside the 167 shadow chain, these will not be 1:1. Instead a pool of available ouputs is 168 maintained with a total balance equal to the total balance inside the 169 shadow chain. The validation rules of upgraded clients ensure that this is 170 always maintained. A legacy client may try to spend these outputs, but it 171 would fail validation under the new rules and quickly become orphaned. 172 173 = Sending money from the visible to the shadow chain = 174 An uncompressed transaction is created with a specially formatted output. 175 176 OP_SHADOW OP_PUSHDATA1 <shadow output> 177 178 Where <shadow output> is a compressed output using the format described in 179 the previous section. 180 181 A legacy client will interpret this as an anyone-can-spend output. An 182 upgraded client will see the OP_SHADOW and interpret this specially, rather 183 than as a normal script. Instead it will interpret the data as a compressed 184 output, and add it as a shadow UTXO, which can be spent by compressed 185 transactions. Additionally, it will note that the visible output can be 186 used later when withdrawing from the shadow chain. 187 188 = Sending money from the shadow chain to the visible chain = 189 An uncompressed transaction is created with a specially formatted input. 190 191 OP_SHADOW OP_PUSHDATA1 <shadow input> 192 193 Where <shadow input> is a compressed input using the format described in 194 the previous section. 195 196 The legacy client will interpret this as spending one of the 197 anyone-can-spend outputs from earlier. The upgraded client will see the 198 leading OP_SHADOW and recognize that it should be interpreted specially. It 199 will perform all the normal verification that <shadow input> is a valid 200 input and not already spent in the shadow chain, etc. Thus the blockchain 201 is seen as valid by both legacy and upgraded clients. 202 203 Note: These scripts are currently considered nonstandard and will not be 204 relayed by legacy clients. As part of implementing the new protocol, 205 upgraded clients will obviously be modified to relay these transactions. 206 Since the consensus step earlier ensures that these are a majority of the 207 network before the changes take effect, this shouldn't be much of a problem. 208 209 = Combining and splitting inputs = 210 211 The above illustrates the simplest case. In practice, it will often by the 212 case that the available pool of OP_SHADOW marked anyone-can-spend UTXOs 213 doesn't match up exactly with the amount being withdrawn. 214 215 If the amounts available are too small, the uncompressed transaction can 216 include multiple inputs. The first one will contain the shadow input data 217 as above, and the subsequent inputs will just say 218 219 OP_SHADOW OP_TRUE 220 221 Likewise, the left over change will be included as an extra output with the 222 script 223 OP_SHADOW 224 225 Each uncompressed transaction can include up to 8 shadow inputs and up to 8 226 shadow outputs. The validation rules require that the total amount of 227 marked anyone-can-spend outputs being spent and created matches up with the 228 total balance leaving and entering the shadow chain. 229 230 What if you want to create an actual anyone-can-spend output under the new 231 rules? Just include an empty script as before. Only scripts that begin with 232 OP_SHADOW take part in the shadow deposit/withdrawal process. 233 234 I hope I explained my idea well enough. It's fairly complex, but I think it 235 works. Unlike the "generalized softfork" proposals, this is a true 236 softfork, as the new blockchain is still valid under the old rules, just 237 interpreted a bit differently. 238 239 --001a11407aac2200b10529779250 240 Content-Type: text/html; charset=UTF-8 241 Content-Transfer-Encoding: quoted-printable 242 243 <div dir=3D"ltr"><span style=3D"font-size:12.8px">Summary: This describes a= 244 new transaction format which allows most transactions to take up less spac= 245 e (and thus fit more per block) and a method to implement it requiring only= 246 a (non generalized) softfork.</span><div style=3D"font-size:12.8px"><br></= 247 div><div style=3D"font-size:12.8px">=3D Compressed transactions =3D</div><d= 248 iv style=3D"font-size:12.8px">This format is designed to allow the majority= 249 of transactions to take up less space, by removing flexibility and unneces= 250 sary data. The requirements to use a compressed transaction are</div><div s= 251 tyle=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">* Non-c= 252 oinbase</div><div style=3D"font-size:12.8px">* 1-8 inputs and 1-8 outputs</= 253 div><div style=3D"font-size:12.8px">* Pay to pubkey hash only</div><div sty= 254 le=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Transacti= 255 ons which want to use arbitrary scripts or a larger number of inputs and ou= 256 tputs can still use the existing transaction format.</div><div style=3D"fon= 257 t-size:12.8px"><br></div><div style=3D"font-size:12.8px">A compressed trans= 258 action consists of</div><div style=3D"font-size:12.8px">header byte, compre= 259 ssed inputs, compressed outputs, optional lock_time</div><div style=3D"font= 260 -size:12.8px"><br></div><div style=3D"font-size:12.8px">header byte has the= 261 following format</div><div style=3D"font-size:12.8px">* bit 7: Always 1, t= 262 o make it easy to distinguish compressed and uncompressed transactions</div= 263 ><div style=3D"font-size:12.8px">* bit 6: 1 if lock_time is used, otherwise= 264 0</div><div style=3D"font-size:12.8px">* bit 5-3: Number of inputs - 1</di= 265 v><div style=3D"font-size:12.8px">* bit 2-0: Number of outputs - 1</div><di= 266 v style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">This= 267 saves 5+ bytes from omitting the version number and the input and output c= 268 ount fields. Additionally, most transactions will not have lock_time, savin= 269 g another 4 bytes.</div><div style=3D"font-size:12.8px"><br></div><div styl= 270 e=3D"font-size:12.8px">Compressed input:</div><div style=3D"font-size:12.8p= 271 x">previous transaction hash, index byte, signature, pubkey, optional seque= 272 nce_no</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-si= 273 ze:12.8px">This has the following differences from a normal input: Index is= 274 only 1 byte, since it is at most 8 anyway. The top bit of the index byte i= 275 ndicates whether the input has a sequence number. ScriptSig length is compl= 276 etely omitted, and signature and public key are included directly, saving s= 277 pace from the data push and check opcodes. And as before, sequence_no is op= 278 tional and usually omitted.</div><div style=3D"font-size:12.8px"><br></div>= 279 <div style=3D"font-size:12.8px">Compressed output:</div><div style=3D"font-= 280 size:12.8px">compressed value (1-7 bytes), pubkeyhash</div><div style=3D"fo= 281 nt-size:12.8px"><br></div><div style=3D"font-size:12.8px">compressed value = 282 format: The high 3 bits of the first byte give the number of following byte= 283 s. The lower 5 bits and the n following bytes comprise the output value. Th= 284 e maximum possible value is=C2=A02099999997690000 satoshis, which requires = 285 7 bytes to encode, but most values will be far shorter. For example, a valu= 286 e of 0.01 BTC could be encoded in just 3 bytes, saving 5.</div><div style= 287 =3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">As before t= 288 he script length field is completely omitted, and the pubkeyhash is include= 289 d directly, without extra opcodes.=C2=A0</div><div style=3D"font-size:12.8p= 290 x"><br></div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-s= 291 ize:12.8px">=3D Consensus =3D=C2=A0</div><div style=3D"font-size:12.8px"><b= 292 r></div><div style=3D"font-size:12.8px">Like all softforks, adoption by a m= 293 inority of miners would cause problems. Therefore, these changes would only= 294 take effect after a consensus. Miners can advertise support for the new fo= 295 rmat by increment the version code. Once X% of Y consecutive blocks have th= 296 is version, the new changes take effect. Users who do not upgrade will stil= 297 l work but will not always see accurate balances in other addresses and min= 298 ers who do not upgrade risk mining an invalid block, encouraging them to up= 299 grade.</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-si= 300 ze:12.8px">=3D The Shadow Chain =3D=C2=A0</div><div style=3D"font-size:12.8= 301 px"><br></div><div style=3D"font-size:12.8px">Now for the interesting part:= 302 Implementing the new format with only a softfork. In order to qualify as a= 303 softfork, every valid block under the new rules also has to be valid under= 304 the old rules.=C2=A0</div><div style=3D"font-size:12.8px"><br></div><div s= 305 tyle=3D"font-size:12.8px">Among other things this means that compressed tra= 306 nsactions can't just be included in place of an ordinary transaction in= 307 a block, since the legacy (non-upgraded) clients will consider that invali= 308 d. Instead, they will be hidden as extra data inside the coinbase transacti= 309 on, which is allowed to contain arbitrary data.=C2=A0</div><div style=3D"fo= 310 nt-size:12.8px"><br></div><div style=3D"font-size:12.8px">Additionally, in = 311 order to support interoperability between compressed and uncompressed trans= 312 actions, uncompressed transactions can hide compressed inputs and ouputs in= 313 side of the normal inputs and outputs using a currently unused opcode (OP_N= 314 OP1, hereafter referred to as OP_SHADOW). OP_SHADOW isn't a script oper= 315 ation per se; instead it marked scripts that should be interpreted differen= 316 tly under the new rules.</div><div style=3D"font-size:12.8px"><br></div><di= 317 v style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">In t= 318 he following, shadow input/output refers to a compressed input/output, whic= 319 h is hidden as metadata and hence not visible to legacy clients.=C2=A0<br><= 320 /div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8= 321 px">The blockchain must also still be valid when all the hidden data is ign= 322 ored. When moving money from the visible to the shadow chain, there is no p= 323 roblem, but when moving money back, things get trickier, since the legacy c= 324 lient won't know about any of the shadow transactions. Therefore, when = 325 sending money to the shadow chain, the transaction includes a specially mar= 326 ked anyone-can-spend output. When moving money back from the shadow chain, = 327 the transaction "spends" any available such outputs.=C2=A0</div><= 328 div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Si= 329 nce an arbitrary amount of splitting and combining can occur inside the sha= 330 dow chain, these will not be 1:1. Instead a pool of available ouputs is mai= 331 ntained with a total balance equal to the total balance inside the shadow c= 332 hain. The validation rules of upgraded clients ensure that this is always m= 333 aintained. A legacy client may try to spend these outputs, but it would fai= 334 l validation under the new rules and quickly become orphaned.</div><div sty= 335 le=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">=3D Sendi= 336 ng money from the visible to the shadow chain =3D</div><div style=3D"font-s= 337 ize:12.8px">An uncompressed transaction is created with a specially formatt= 338 ed output.</div><div style=3D"font-size:12.8px"><br></div><div style=3D"fon= 339 t-size:12.8px">OP_SHADOW OP_PUSHDATA1 <shadow output></div><div style= 340 =3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Where <s= 341 hadow output> is a compressed output using the format described in the p= 342 revious section.</div><div style=3D"font-size:12.8px"><br></div><div style= 343 =3D"font-size:12.8px">A legacy client will interpret this as an anyone-can-= 344 spend output. An upgraded client will see the OP_SHADOW and interpret this = 345 specially, rather than as a normal script. Instead it will interpret the da= 346 ta as a compressed output, and add it as a shadow UTXO, which can be spent = 347 by compressed transactions. Additionally, it will note that the visible out= 348 put can be used later when withdrawing from the shadow chain.</div><div sty= 349 le=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">=3D Sendi= 350 ng money from the shadow chain to the visible chain =3D</div><div style=3D"= 351 font-size:12.8px">An uncompressed transaction is created with a specially f= 352 ormatted input.<br></div><div style=3D"font-size:12.8px"><br></div><div sty= 353 le=3D"font-size:12.8px">OP_SHADOW OP_PUSHDATA1 <shadow input></div><d= 354 iv style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Whe= 355 re <shadow input> is a compressed input using the format described in= 356 the previous section.<br></div><div style=3D"font-size:12.8px"><br></div><= 357 div style=3D"font-size:12.8px">The legacy client will interpret this as spe= 358 nding one of the anyone-can-spend outputs from earlier. The upgraded client= 359 will see the leading OP_SHADOW and recognize that it should be interpreted= 360 specially. It will perform all the normal verification that <shadow inp= 361 ut> is a valid input and not already spent in the shadow chain, etc. Thu= 362 s the blockchain is seen as valid by both legacy and upgraded clients.</div= 363 ><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">= 364 Note: These scripts are currently considered nonstandard and will not be re= 365 layed by legacy clients. As part of implementing the new protocol, upgraded= 366 clients will obviously be modified to relay these transactions. Since the = 367 consensus step earlier ensures that these are a majority of the network bef= 368 ore the changes take effect, this shouldn't be much of a problem.</div>= 369 <div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">= 370 =3D Combining and splitting inputs =3D=C2=A0</div><div style=3D"font-size:1= 371 2.8px"><br></div><div style=3D"font-size:12.8px">The above illustrates the = 372 simplest case. In practice, it will often by the case that the available po= 373 ol of OP_SHADOW marked anyone-can-spend UTXOs doesn't match up exactly = 374 with the amount being withdrawn.=C2=A0</div><div style=3D"font-size:12.8px"= 375 ><br></div><div style=3D"font-size:12.8px">If the amounts available are too= 376 small, the uncompressed transaction can include multiple inputs. The first= 377 one will contain the shadow input data as above, and the subsequent inputs= 378 will just say=C2=A0</div><div style=3D"font-size:12.8px"><br></div><div st= 379 yle=3D"font-size:12.8px">OP_SHADOW OP_TRUE</div><div style=3D"font-size:12.= 380 8px"><br></div><div style=3D"font-size:12.8px">Likewise, the left over chan= 381 ge will be included as an extra output with the script</div><div style=3D"f= 382 ont-size:12.8px">OP_SHADOW</div><div style=3D"font-size:12.8px"><br></div><= 383 div style=3D"font-size:12.8px">Each uncompressed transaction can include up= 384 to 8 shadow inputs and up to 8 shadow outputs. The validation rules requir= 385 e that the total amount of marked anyone-can-spend outputs being spent and = 386 created matches up with the total balance leaving and entering the shadow c= 387 hain.=C2=A0</div><div style=3D"font-size:12.8px"><br></div><div style=3D"fo= 388 nt-size:12.8px">What if you want to create an actual anyone-can-spend outpu= 389 t under the new rules? Just include an empty script as before. Only scripts= 390 that begin with OP_SHADOW take part in the shadow deposit/withdrawal proce= 391 ss.<br></div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-s= 392 ize:12.8px">I hope I explained my idea well enough. It's fairly complex= 393 , but I think it works. Unlike the "generalized softfork" proposa= 394 ls, this is a true softfork, as the new blockchain is still valid under the= 395 old rules, just interpreted a bit differently.</div></div> 396 397 --001a11407aac2200b10529779250-- 398