8c8ebca01ce449f8c465a59e661be6fa5fd1ac
1 Return-Path: <jannes.faber@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 AADA4273 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Wed, 25 Nov 2015 00:38:06 +0000 (UTC) 7 X-Greylist: whitelisted by SQLgrey-1.7.6 8 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com 9 [209.85.215.51]) 10 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D528159 11 for <bitcoin-dev@lists.linuxfoundation.org>; 12 Wed, 25 Nov 2015 00:38:05 +0000 (UTC) 13 Received: by lfaz4 with SMTP id z4so42094745lfa.0 14 for <bitcoin-dev@lists.linuxfoundation.org>; 15 Tue, 24 Nov 2015 16:38:03 -0800 (PST) 16 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 17 h=mime-version:in-reply-to:references:date:message-id:subject:from:to 18 :content-type; bh=3LV8FzdfCTpPGEOOP4ub+G9HGRd12pgOYlajCFXAI64=; 19 b=ouYDOf53HKSKKh0/P3aXJAJ0YtxaHeNxCUb5s1H0691zQBPSL2M8jTXZYAHVmCG32w 20 XZmCJuN369hKXkmKYUD/oUoIY9iT9s8jmPow6ayyzRlbh67YN6QmH2oKloq3vV76oUPM 21 0ZrpciIcuqNuNguUeEgb2ZBAvqzT70OLAyfUzvz9tjH40UrYt6wY5RvdfWI2b7oRm7Mt 22 dmWcoHTR79N6terDE9/XbQqFh1FKZPbKE6CUbAIN/+PblTJ0yn6ASy9AMGWZRQ2IIFhY 23 ode8oZwjClnN+q5LGa05dovQjFxTdg9uka/qtldG1b1GzXvo+NW0mt/CKhV7AbLbJZB9 24 MwuA== 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:in-reply-to:references:date 28 :message-id:subject:from:to:content-type; 29 bh=3LV8FzdfCTpPGEOOP4ub+G9HGRd12pgOYlajCFXAI64=; 30 b=ZQhEGNDaeDT24r/r8NwQfQelWoLjw8T2NIo26u6DzRlu5FoQAX6KENs6kmErHie0ld 31 H21f3rV0W4ENE4mHT3q8iLm8tC+XAS04agt2pqZP1ThcFft/e/cWg4fQB+etf+HIb8qo 32 65UMVPU4Eg1txTbo94eeKQtSlIAMLogmDkcRf2+cqRoSLJzjK5XANtHvCdAovFbbBTj4 33 HOPqjakFdJt9qQbdiRI7QCVs5K39z3U/e8rkda0Vwle/YEOfWY8+uSMLSIL2x1MEjaLe 34 at24L9EwpfDEjOTDk9rZ1sSVyT6P7bEC5XCyEKekA6W7OrOlRYPagNvrPaBG2lugQWwj 35 9ECg== 36 X-Received: by 10.112.138.10 with SMTP id qm10mr11976978lbb.139.1448411883622; 37 Tue, 24 Nov 2015 16:38:03 -0800 (PST) 38 Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. 39 [209.85.215.48]) by smtp.gmail.com with ESMTPSA id 40 vz2sm2937219lbb.35.2015.11.24.16.38.02 41 for <bitcoin-dev@lists.linuxfoundation.org> 42 (version=TLSv1/SSLv3 cipher=OTHER); 43 Tue, 24 Nov 2015 16:38:02 -0800 (PST) 44 Received: by lffu14 with SMTP id u14so42133794lff.1 45 for <bitcoin-dev@lists.linuxfoundation.org>; 46 Tue, 24 Nov 2015 16:38:02 -0800 (PST) 47 X-Gm-Message-State: ALoCoQkyVlVOzflrkIL25K0Hfl63JClzxf0ZLm7irFHE405EaNQtc5/vB7jD67af39Ti5ujFtcEJ 48 MIME-Version: 1.0 49 X-Received: by 10.112.119.133 with SMTP id ku5mr13954750lbb.1.1448411882359; 50 Tue, 24 Nov 2015 16:38:02 -0800 (PST) 51 Received: by 10.112.157.199 with HTTP; Tue, 24 Nov 2015 16:38:02 -0800 (PST) 52 Received: by 10.112.157.199 with HTTP; Tue, 24 Nov 2015 16:38:02 -0800 (PST) 53 In-Reply-To: <CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com> 54 References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com> 55 <CABaSBaxKJjEd2e9hrnzyS57-YHspqCv9PiSH4XccqSZJMQG6qg@mail.gmail.com> 56 <CAGLBAhd-6NbxppFdqNVSQ5ot_GX12eL8P2-qVe7_dZcUfHYv6w@mail.gmail.com> 57 <CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com> 58 Date: Wed, 25 Nov 2015 01:38:02 +0100 59 X-Gmail-Original-Message-ID: <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com> 60 Message-ID: <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com> 61 From: Jannes Faber <jannes.faber@gmail.com> 62 To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> 63 Content-Type: multipart/alternative; boundary=047d7bb040cebcab60052552ab56 64 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, 65 DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 66 autolearn=ham version=3.3.1 67 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 68 smtp1.linux-foundation.org 69 X-Mailman-Approved-At: Wed, 25 Nov 2015 00:41:45 +0000 70 Subject: Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or 71 "Coalescing Transactions" 72 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 73 X-Mailman-Version: 2.1.12 74 Precedence: list 75 List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> 76 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 77 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 78 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 79 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 80 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 81 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 82 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 83 X-List-Received-Date: Wed, 25 Nov 2015 00:38:06 -0000 84 85 --047d7bb040cebcab60052552ab56 86 Content-Type: text/plain; charset=UTF-8 87 88 Few issues I can think of: 89 90 1. In its basic form this encourages address reuse. Unless the wildcard can 91 be constructed such that it can match a whole branch of an HD wallet. 92 Although I guess that would tie all those addresses together making HD moot 93 to begin with. 94 95 2. Sounds pretty dangerous during reorgs. Maybe such a transaction should 96 include a block height which indicates the maximum block that any utxo can 97 match. With the requirement that the specified block height is at least 100 98 blocks in the past. Maybe add a minimum block height as well to prevent 99 unnecessary scanning (with the requirement that at least one utxo must be 100 in that minimum block). 101 102 3. Seems like a nice way to the reduce utxo set. But hard to say how 103 effective it would really be. 104 On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" < 105 bitcoin-dev@lists.linuxfoundation.org> wrote: 106 107 > > This idea could be applied by having the wildcard signature apply to all 108 > > UTXOs that are of a standard form and paid to a particular address, and 109 > be 110 > > a signature of some kind of message to that effect. 111 > 112 > I think this is true. Not *all* transactions will be able to match the 113 > wildcard. For instance if someone sent some crazy smart contract tx to 114 > your address, the script associated with that tx will be such that it 115 > will not apply to the wildcard. Most "vanilla" utxos that I've seen 116 > have the formula: OP_DUP OP_HASH160 [a hash corresponding to your 117 > address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could 118 > apply to the wildcard. 119 > 120 > On 11/24/15, Dave Scotese via bitcoin-dev 121 > <bitcoin-dev@lists.linuxfoundation.org> wrote: 122 > > What is required to spend bitcoin is that input be provided to the UTXO 123 > > script that causes it to return true. What Chris is proposing breaks the 124 > > programmatic nature of the requirement, replacing it with a requirement 125 > > that the secret be known. Granted, the secret is the only requirement in 126 > > most cases, but there is no built-in assumption that the script always 127 > > requires only that secret. 128 > > 129 > > This idea could be applied by having the wildcard signature apply to all 130 > > UTXOs that are of a standard form and paid to a particular address, and 131 > be 132 > > a signature of some kind of message to that effect. I imagine the cost 133 > of 134 > > re-scanning the UTXO set to find them all would justify a special extra 135 > > mining fee for any transaction that used this opcode. 136 > > 137 > > Please be blunt about any of my own misunderstandings that this email 138 > makes 139 > > clear. 140 > > 141 > > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev < 142 > > bitcoin-dev@lists.linuxfoundation.org> wrote: 143 > > 144 > >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev < 145 > >> bitcoin-dev@lists.linuxfoundation.org> wrote: 146 > >> 147 > >>> **OP_CHECKWILDCARDSIGVERIFY** 148 > >> 149 > >> 150 > >> Some (minor) discussion of this idea in -wizards earlier today starting 151 > >> near near "09:50" (apologies for having no anchor links): 152 > >> http://gnusha.org/bitcoin-wizards/2015-11-24.log 153 > >> 154 > >> - Bryan 155 > >> http://heybryan.org/ 156 > >> 1 512 203 0507 157 > >> 158 > >> _______________________________________________ 159 > >> bitcoin-dev mailing list 160 > >> bitcoin-dev@lists.linuxfoundation.org 161 > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 162 > >> 163 > >> 164 > > 165 > > 166 > > -- 167 > > I like to provide some work at no charge to prove my value. Do you need a 168 > > techie? 169 > > I own Litmocracy <http://www.litmocracy.com> and Meme Racing 170 > > <http://www.memeracing.net> (in alpha). 171 > > I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> 172 > which 173 > > now accepts Bitcoin. 174 > > I also code for The Dollar Vigilante <http://dollarvigilante.com/>. 175 > > "He ought to find it more profitable to play by the rules" - Satoshi 176 > > Nakamoto 177 > > 178 > _______________________________________________ 179 > bitcoin-dev mailing list 180 > bitcoin-dev@lists.linuxfoundation.org 181 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 182 > 183 184 --047d7bb040cebcab60052552ab56 185 Content-Type: text/html; charset=UTF-8 186 Content-Transfer-Encoding: quoted-printable 187 188 <p dir=3D"ltr">Few issues I can think of:</p> 189 <p dir=3D"ltr">1. In its basic form this encourages address reuse. Unless t= 190 he wildcard can be constructed such that it can match a whole branch of an = 191 HD=C2=A0 wallet. Although I guess that would tie all those addresses togeth= 192 er making HD moot to begin with.</p> 193 <p dir=3D"ltr">2. Sounds pretty dangerous during reorgs. Maybe such a trans= 194 action should include a block height which indicates the maximum block that= 195 any utxo can match. With the requirement that the specified block height i= 196 s at least 100 blocks in the past. Maybe add a minimum block height as well= 197 to prevent unnecessary scanning (with the requirement that at least one ut= 198 xo must be in that minimum block).</p> 199 <p dir=3D"ltr">3. Seems like a nice way to the reduce utxo set. But hard to= 200 say how effective it would really be.</p> 201 <div class=3D"gmail_quote">On 25 Nov 2015 12:48 a.m., "Chris Priest vi= 202 a bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= 203 .org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attri= 204 bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= 205 -left:1px #ccc solid;padding-left:1ex">> This idea could be applied by h= 206 aving the wildcard signature apply to all<br> 207 > UTXOs that are of a standard form and paid to a particular address, an= 208 d be<br> 209 > a signature of some kind of message to that effect.<br> 210 <br> 211 I think this is true. Not *all* transactions will be able to match the<br> 212 wildcard. For instance if someone sent some crazy smart contract tx to<br> 213 your address, the script associated with that tx will be such that it<br> 214 will not apply to the wildcard. Most "vanilla" utxos that I'v= 215 e seen<br> 216 have the formula: OP_DUP OP_HASH160 [a hash corresponding to your<br> 217 address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could<br= 218 > 219 apply to the wildcard.<br> 220 <br> 221 On 11/24/15, Dave Scotese via bitcoin-dev<br> 222 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= 223 sts.linuxfoundation.org</a>> wrote:<br> 224 > What is required to spend bitcoin is that input be provided to the UTX= 225 O<br> 226 > script that causes it to return true.=C2=A0 What Chris is proposing br= 227 eaks the<br> 228 > programmatic nature of the requirement, replacing it with a requiremen= 229 t<br> 230 > that the secret be known.=C2=A0 Granted, the secret is the only requir= 231 ement in<br> 232 > most cases, but there is no built-in assumption that the script always= 233 <br> 234 > requires only that secret.<br> 235 ><br> 236 > This idea could be applied by having the wildcard signature apply to a= 237 ll<br> 238 > UTXOs that are of a standard form and paid to a particular address, an= 239 d be<br> 240 > a signature of some kind of message to that effect.=C2=A0 I imagine th= 241 e cost of<br> 242 > re-scanning the UTXO set to find them all would justify a special extr= 243 a<br> 244 > mining fee for any transaction that used this opcode.<br> 245 ><br> 246 > Please be blunt about any of my own misunderstandings that this email = 247 makes<br> 248 > clear.<br> 249 ><br> 250 > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <<br> 251 > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= 252 ists.linuxfoundation.org</a>> wrote:<br> 253 ><br> 254 >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <= 255 ;<br> 256 >> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= 257 ev@lists.linuxfoundation.org</a>> wrote:<br> 258 >><br> 259 >>> **OP_CHECKWILDCARDSIGVERIFY**<br> 260 >><br> 261 >><br> 262 >> Some (minor) discussion of this idea in -wizards earlier today sta= 263 rting<br> 264 >> near near "09:50" (apologies for having no anchor links)= 265 :<br> 266 >> <a href=3D"http://gnusha.org/bitcoin-wizards/2015-11-24.log" rel= 267 =3D"noreferrer" target=3D"_blank">http://gnusha.org/bitcoin-wizards/2015-11= 268 -24.log</a><br> 269 >><br> 270 >> - Bryan<br> 271 >> <a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_bla= 272 nk">http://heybryan.org/</a><br> 273 >> 1 512 203 0507<br> 274 >><br> 275 >> _______________________________________________<br> 276 >> bitcoin-dev mailing list<br> 277 >> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= 278 ev@lists.linuxfoundation.org</a><br> 279 >> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc= 280 oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation= 281 .org/mailman/listinfo/bitcoin-dev</a><br> 282 >><br> 283 >><br> 284 ><br> 285 ><br> 286 > --<br> 287 > I like to provide some work at no charge to prove my value. Do you nee= 288 d a<br> 289 > techie?<br> 290 > I own Litmocracy <<a href=3D"http://www.litmocracy.com" rel=3D"nore= 291 ferrer" target=3D"_blank">http://www.litmocracy.com</a>> and Meme Racing= 292 <br> 293 > <<a href=3D"http://www.memeracing.net" rel=3D"noreferrer" target=3D= 294 "_blank">http://www.memeracing.net</a>> (in alpha).<br> 295 > I'm the webmaster for The Voluntaryist <<a href=3D"http://www.v= 296 oluntaryist.com" rel=3D"noreferrer" target=3D"_blank">http://www.voluntaryi= 297 st.com</a>> which<br> 298 > now accepts Bitcoin.<br> 299 > I also code for The Dollar Vigilante <<a href=3D"http://dollarvigil= 300 ante.com/" rel=3D"noreferrer" target=3D"_blank">http://dollarvigilante.com/= 301 </a>>.<br> 302 > "He ought to find it more profitable to play by the rules" -= 303 Satoshi<br> 304 > Nakamoto<br> 305 ><br> 306 _______________________________________________<br> 307 bitcoin-dev mailing list<br> 308 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= 309 linuxfoundation.org</a><br> 310 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 311 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= 312 man/listinfo/bitcoin-dev</a><br> 313 </blockquote></div> 314 315 --047d7bb040cebcab60052552ab56-- 316