Return-Path: <trevinhofmann@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 608A685 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 25 Nov 2015 15:41:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F790161 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 25 Nov 2015 15:41:03 +0000 (UTC) Received: by wmec201 with SMTP id c201so75382872wme.1 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 25 Nov 2015 07:41:02 -0800 (PST) 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; bh=r2i3m5ciK99shN7PAnAkz4lZ4QX1kuckZ+rzkVXEcw0=; b=Er/47lAM22gSm990rjTJb5BxnC6MMTyI5sdj/LlD5iOhds2+u6dIWZo8Zpmhc0OiVA JpzPpezicOnvgmbM6+QGbo85oLdwOjR0TkHSCU9yus5dRUV9K8hQQqgy8JxrlJ4kDMNp inu8G+8ymRExC0B9IhasxOYtX7dB5CU5ZLfFZWLGUst+DQTbisobJSCly3wb6jusecSC Uk9u/9Hr1dW1u14CwOlZa8eXSkaCuL863XiSx6lQwZktGofI4SdN90ZMaBtFATdw+Ieh Lwn+3I5WQOgfPHP4UDWxj8KdUQ1/rhksIlNmfzOG1I89/cZdMY+fCWl9YMbpy/AKOtN6 TUnA== MIME-Version: 1.0 X-Received: by 10.194.246.132 with SMTP id xw4mr43983109wjc.75.1448466062170; Wed, 25 Nov 2015 07:41:02 -0800 (PST) Received: by 10.194.33.170 with HTTP; Wed, 25 Nov 2015 07:41:01 -0800 (PST) Received: by 10.194.33.170 with HTTP; Wed, 25 Nov 2015 07:41:01 -0800 (PST) In-Reply-To: <5655C2AE.6040404@startmail.com> References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com> <CABaSBaxKJjEd2e9hrnzyS57-YHspqCv9PiSH4XccqSZJMQG6qg@mail.gmail.com> <CAGLBAhd-6NbxppFdqNVSQ5ot_GX12eL8P2-qVe7_dZcUfHYv6w@mail.gmail.com> <CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com> <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com> <CAAcC9yuUYx5o50ocTiFp2keYUuew8aT5fuCnx-huHUgeGK5r1g@mail.gmail.com> <5655C2AE.6040404@startmail.com> Date: Wed, 25 Nov 2015 09:41:01 -0600 Message-ID: <CALd2G5dYpf1pAM=8e+gnyT9j82qrKk-nhswGyk9HyysKtWkCmA@mail.gmail.com> From: Trevin Hofmann <trevinhofmann@gmail.com> To: Erik <erik.fors@startmail.com> Content-Type: multipart/alternative; boundary=089e0168199e1ae73e05255f49d6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 X-Mailman-Approved-At: Wed, 25 Nov 2015 15:44:29 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" 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: Wed, 25 Nov 2015 15:41:05 -0000 --089e0168199e1ae73e05255f49d6 Content-Type: text/plain; charset=UTF-8 > Considering the website example, where most websites uses static content, a bitcoin address could accumulate a dozen of transactions before the webmaster changes the address to a new one. Would this use case be a better match for something such as stealth addresses or hierarchical deterministic addresses? Trevin Hofmann On Nov 25, 2015 8:16 AM, "Erik via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Nice idea. I see it as an important feature because of several reasons: > > Considering the website example, where most websites uses static > content, a bitcoin address could accumulate a dozen of transactions > before the webmaster changes the address to a new one. > > Also consider a QR-code address printed on paper. That address is also > prone to multiple payments, which could be several small ones. > > You ask someone to pay an amount of BTC. That person would be someone > that want you to actually don't get any money at all, so instead of > sending one payment, the person sends a lot of small TXes. It costs a > lot more to achieve this, but that doesn't bother the person sending the > transactions. What you see is the transactions to the address you've > agreed sum up to the amount you asked for. When you later try to spend > it, you can't because of that the size of all UXTOs is too high to even > overcome the tx fee. > > If you use a wildcard transaction to bake them together into one UXTO, > you will not need to pay more than just one tx fee to solve the problem > you've got. Also the network will benefit from this because the > alternative is to not spend those UXTOs at all because it costs more > than it earns, leaving lots of UXTOs in the databases. > > Some problems to consider is: > * Which addresses should be involved in a wildcard TX. > * How to not make it repeatable or delayed so that UXTOs not intended to > be in that TX wouldn't be included. > * How to make it impossible to sign an wildcard TX with a future date. > * How to limit outputs so they not are in risk being double-spent. > * How to guarantee that the output is actually calculated from all the > inputs involved and not less, making insane TX fees available. > > I could see possible solutions to this problems: > * Using the highest block height number of transactions to include or > maybe better, the UXTO of one transaction destined to that address > involved in that block - that implies collecting all UXTOs in that block. > * Using a signature that includes the date. To let it be present more > times in the blockchain requires another timestamp that is newer than a > wildcard TX already existing in the blockchain. Also make the > transaction invalid to put in a block if the timestamp is behind a > certain time or in the future. > * Using the coinbase UXTO or the block hash from the latest block as > proof that the transaction isn't created earlier than that. Also makes > the wildcard TX invalid if that block isn't part of the blockchain > anymore. This also have a secondary effect of certifying the blockchain > itself making it more difficult to fork it from far behind because it > will effectively remove all transactions depending on a UXTO including > this type of certification. > * Either using a priority like way to determine what are being left to > wildcard in a block - all transactions spending UXTOs of that address is > removed before the wildcard TX if they occurs in the same block. Either > it is possible to set a rule that if a wildcard TX exists in one block, > it is invalid to include other UXTOs that is to be be included in the > wildcard from the same address in the same block. (Classic > double-spending rule) > * Using a special form of output specifying only one destination > address/script and the amount of fees to pay. If the amount of fees > could be payed, then the rest will be sent to the destination address. > This covers intentional delaying and also discourage forking the > blockchain by miners to making the signature UXTO appear later than more > recent transaction in a new fork to collect the later txes as fee. > > This transaction type would in fact look like a time-limited offer to > the network to reduce the UXTO set of an address. I guess some miners > will then use a logic that prefers this types of TXes even if they are > low-fee because, if they removes lots of UXTOs, they benefits the network. > > Sincerely, > Erik. > > Den 2015-11-25 kl. 02:26, skrev Chris Priest via bitcoin-dev: > > 1. Technically is it promoting address reuse, but in this case, I > > think it's OK. The primary purpose of a coalescing transaction is to > > clear out *all* funds associated with one address and send them to > > another address (belonging to the same owner). If you coalesce the > > inputs to the same address over and over again, you an do that, but > > you'll run the risk of leaking your private key. > > > > 2. I see these transactions being broadcast in the background when the > > user is not planning on sending or receiving any payments. By the time > > the wallet user wants to spend funds from the address, the coalescing > > transaction should be sufficiently deep enough in the blockchain to > > avoid re-org tomfoolery. Exchanges and payment processors who take in > > payments around the clock will probably never use these transactions, > > at least not on "live" addresses. > > > > 3. I never thought of that, but thats a benefit too! > > > > On 11/24/15, Jannes Faber via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Few issues I can think of: > >> > >> 1. In its basic form this encourages address reuse. Unless the > wildcard can > >> be constructed such that it can match a whole branch of an HD wallet. > >> Although I guess that would tie all those addresses together making > HD moot > >> to begin with. > >> > >> 2. Sounds pretty dangerous during reorgs. Maybe such a transaction > should > >> include a block height which indicates the maximum block that any > utxo can > >> match. With the requirement that the specified block height is at > least 100 > >> blocks in the past. Maybe add a minimum block height as well to prevent > >> unnecessary scanning (with the requirement that at least one utxo must > be > >> in that minimum block). > >> > >> 3. Seems like a nice way to the reduce utxo set. But hard to say how > >> effective it would really be. > >> On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" < > >> bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > >>>> This idea could be applied by having the wildcard signature apply to > >>>> all > >>>> UTXOs that are of a standard form and paid to a particular address, > and > >>> be > >>>> a signature of some kind of message to that effect. > >>> > >>> I think this is true. Not *all* transactions will be able to match the > >>> wildcard. For instance if someone sent some crazy smart contract tx to > >>> your address, the script associated with that tx will be such that it > >>> will not apply to the wildcard. Most "vanilla" utxos that I've seen > >>> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your > >>> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could > >>> apply to the wildcard. > >>> > >>> On 11/24/15, Dave Scotese via bitcoin-dev > >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: > >>>> What is required to spend bitcoin is that input be provided to the > UTXO > >>>> script that causes it to return true. What Chris is proposing breaks > >>>> the > >>>> programmatic nature of the requirement, replacing it with a > requirement > >>>> that the secret be known. Granted, the secret is the only requirement > >>>> in > >>>> most cases, but there is no built-in assumption that the script always > >>>> requires only that secret. > >>>> > >>>> This idea could be applied by having the wildcard signature apply to > >>>> all > >>>> UTXOs that are of a standard form and paid to a particular address, > and > >>> be > >>>> a signature of some kind of message to that effect. I imagine the > cost > >>> of > >>>> re-scanning the UTXO set to find them all would justify a special > extra > >>>> mining fee for any transaction that used this opcode. > >>>> > >>>> Please be blunt about any of my own misunderstandings that this email > >>> makes > >>>> clear. > >>>> > >>>> On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev < > >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: > >>>> > >>>>> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev < > >>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: > >>>>> > >>>>>> **OP_CHECKWILDCARDSIGVERIFY** > >>>>> > >>>>> > >>>>> Some (minor) discussion of this idea in -wizards earlier today > >>>>> starting > >>>>> near near "09:50" (apologies for having no anchor links): > >>>>> http://gnusha.org/bitcoin-wizards/2015-11-24.log > >>>>> > >>>>> - Bryan > >>>>> http://heybryan.org/ > >>>>> 1 512 203 0507 > >>>>> > >>>>> _______________________________________________ > >>>>> bitcoin-dev mailing list > >>>>> bitcoin-dev@lists.linuxfoundation.org > >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> I like to provide some work at no charge to prove my value. Do you > need > >>>> a > >>>> techie? > >>>> I own Litmocracy <http://www.litmocracy.com> and Meme Racing > >>>> <http://www.memeracing.net> (in alpha). > >>>> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> > >>> which > >>>> now accepts Bitcoin. > >>>> I also code for The Dollar Vigilante <http://dollarvigilante.com/>. > >>>> "He ought to find it more profitable to play by the rules" - Satoshi > >>>> Nakamoto > >>>> > >>> _______________________________________________ > >>> bitcoin-dev mailing list > >>> bitcoin-dev@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>> > >> > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1 > DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx > 946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd > fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG > Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI > TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI > 8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o > ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm > /h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU > xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz > 2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW > E6sERK8uG8S3KdBSVQ7K > =1xdi > -----END PGP SIGNATURE----- > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e0168199e1ae73e05255f49d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">> Considering the website example, where most websites us= es static<br> content, a bitcoin address could accumulate a dozen of transactions<br> before the webmaster changes the address to a new one.</p> <p dir=3D"ltr">Would this use case be a better match for something such as = stealth addresses or hierarchical deterministic addresses?<br></p> <p dir=3D"ltr">Trevin Hofmann</p> <div class=3D"gmail_quote">On Nov 25, 2015 8:16 AM, "Erik via bitcoin-= dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= oin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"><br> -----BEGIN PGP SIGNED MESSAGE-----<br> Hash: SHA1<br> <br> <br> Nice idea. I see it as an important feature because of several reasons:<br> <br> Considering the website example, where most websites uses static<br> content, a bitcoin address could accumulate a dozen of transactions<br> before the webmaster changes the address to a new one.<br> <br> Also consider a QR-code address printed on paper. That address is also<br> prone to multiple payments, which could be several small ones.<br> <br> You ask someone to pay an amount of BTC. That person would be someone<br> that want you to actually don't get any money at all, so instead of<br> sending one payment, the person sends a lot of small TXes. It costs a<br> lot more to achieve this, but that doesn't bother the person sending th= e<br> transactions. What you see is the transactions to the address you've<br= > agreed sum up to the amount you asked for. When you later try to spend<br> it, you can't because of that the size of all UXTOs is too high to even= <br> overcome the tx fee.<br> <br> If you use a wildcard transaction to bake them together into one UXTO,<br> you will not need to pay more than just one tx fee to solve the problem<br> you've got. Also the network will benefit from this because the<br> alternative is to not spend those UXTOs at all because it costs more<br> than it earns, leaving lots of UXTOs in the databases.<br> <br> Some problems to consider is:<br> * Which addresses should be involved in a wildcard TX.<br> * How to not make it repeatable or delayed so that UXTOs not intended to<br= > be in that TX wouldn't be included.<br> * How to make it impossible to sign an wildcard TX with a future date.<br> * How to limit outputs so they not are in risk being double-spent.<br> * How to guarantee that the output is actually calculated from all the<br> inputs involved and not less, making insane TX fees available.<br> <br> I could see possible solutions to this problems:<br> * Using the highest block height number of transactions to include or<br> maybe better, the UXTO of one transaction destined to that address<br> involved in that block - that implies collecting all UXTOs in that block.<b= r> * Using a signature that includes the date. To let it be present more<br> times in the blockchain requires another timestamp that is newer than a<br> wildcard TX already existing in the blockchain. Also make the<br> transaction invalid to put in a block if the timestamp is behind a<br> certain time or in the future.<br> * Using the coinbase UXTO or the block hash from the latest block as<br> proof that the transaction isn't created earlier than that. Also makes<= br> the wildcard TX invalid if that block isn't part of the blockchain<br> anymore. This also have a secondary effect of certifying the blockchain<br> itself making it more difficult to fork it from far behind because it<br> will effectively remove all transactions depending on a UXTO including<br> this type of certification.<br> * Either using a priority like way to determine what are being left to<br> wildcard in a block - all transactions spending UXTOs of that address is<br= > removed before the wildcard TX if they occurs in the same block. Either<br> it is possible to set a rule that if a wildcard TX exists in one block,<br> it is invalid to include other UXTOs that is to be be included in the<br> wildcard from the same address in the same block. (Classic<br> double-spending rule)<br> * Using a special form of output specifying only one destination<br> address/script and the amount of fees to pay. If the amount of fees<br> could be payed, then the rest will be sent to the destination address.<br> This covers intentional delaying and also discourage forking the<br> blockchain by miners to making the signature UXTO appear later than more<br= > recent transaction in a new fork to collect the later txes as fee.<br> <br> This transaction type would in fact look like a time-limited offer to<br> the network to reduce the UXTO set of an address. I guess some miners<br> will then use a logic that prefers this types of TXes even if they are<br> low-fee because, if they removes lots of UXTOs, they benefits the network.<= br> <br> Sincerely,<br> Erik.<br> <br> Den 2015-11-25 kl. 02:26, skrev Chris Priest via bitcoin-dev:<br> > 1. Technically is it promoting address reuse, but in this case, I<br> > think it's OK. The primary purpose of a coalescing transaction is = to<br> > clear out *all* funds associated with one address and send them to<br> > another address (belonging to the same owner). If you coalesce the<br> > inputs to the same address over and over again, you an do that, but<br= > > you'll run the risk of leaking your private key.<br> ><br> > 2. I see these transactions being broadcast in the background when the= <br> > user is not planning on sending or receiving any payments. By the time= <br> > the wallet user wants to spend funds from the address, the coalescing<= br> > transaction should be sufficiently deep enough in the blockchain to<br= > > avoid re-org tomfoolery. Exchanges and payment processors who take in<= br> > payments around the clock will probably never use these transactions,<= br> > at least not on "live" addresses.<br> ><br> > 3. I never thought of that, but thats a benefit too!<br> ><br> > On 11/24/15, Jannes Faber via bitcoin-dev<br> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= ev@lists.linuxfoundation.org</a>> wrote:<br> >> Few issues I can think of:<br> >><br> >> 1. In its basic form this encourages address reuse. Unless the<br> wildcard can<br> >> be constructed such that it can match a whole branch of an HD=C2= =A0 wallet.<br> >> Although I guess that would tie all those addresses together makin= g<br> HD moot<br> >> to begin with.<br> >><br> >> 2. Sounds pretty dangerous during reorgs. Maybe such a transaction= should<br> >> include a block height which indicates the maximum block that any<= br> utxo can<br> >> match. With the requirement that the specified block height is at<= br> least 100<br> >> blocks in the past. Maybe add a minimum block height as well to pr= event<br> >> unnecessary scanning (with the requirement that at least one utxo = must be<br> >> in that minimum block).<br> >><br> >> 3. Seems like a nice way to the reduce utxo set. But hard to say h= ow<br> >> effective it would really be.<br> >> On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev"= ; <<br> >> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= ev@lists.linuxfoundation.org</a>> wrote:<br> >><br> >>>> This idea could be applied by having the wildcard signatur= e apply to<br> >>>> all<br> >>>> UTXOs that are of a standard form and paid to a particular= address, and<br> >>> be<br> >>>> a signature of some kind of message to that effect.<br> >>><br> >>> I think this is true. Not *all* transactions will be able to m= atch the<br> >>> wildcard. For instance if someone sent some crazy smart contra= ct tx to<br> >>> your address, the script associated with that tx will be such = that it<br> >>> will not apply to the wildcard. Most "vanilla" utxos= that I've seen<br> >>> have the formula: OP_DUP OP_HASH160 [a hash corresponding to y= our<br> >>> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that = form could<br> >>> apply to the wildcard.<br> >>><br> >>> On 11/24/15, Dave Scotese via bitcoin-dev<br> >>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b= itcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> >>>> What is required to spend bitcoin is that input be provide= d to the UTXO<br> >>>> script that causes it to return true.=C2=A0 What Chris is = proposing breaks<br> >>>> the<br> >>>> programmatic nature of the requirement, replacing it with = a requirement<br> >>>> that the secret be known.=C2=A0 Granted, the secret is the= only requirement<br> >>>> in<br> >>>> most cases, but there is no built-in assumption that the s= cript always<br> >>>> requires only that secret.<br> >>>><br> >>>> This idea could be applied by having the wildcard signatur= e apply to<br> >>>> all<br> >>>> UTXOs that are of a standard form and paid to a particular= address, and<br> >>> be<br> >>>> a signature of some kind of message to that effect.=C2=A0 = I imagine the cost<br> >>> of<br> >>>> re-scanning the UTXO set to find them all would justify a = special extra<br> >>>> mining fee for any transaction that used this opcode.<br> >>>><br> >>>> Please be blunt about any of my own misunderstandings that= this email<br> >>> makes<br> >>>> clear.<br> >>>><br> >>>> On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-= dev <<br> >>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b= itcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> >>>><br> >>>>> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bit= coin-dev <<br> >>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= g">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> >>>>><br> >>>>>> **OP_CHECKWILDCARDSIGVERIFY**<br> >>>>><br> >>>>><br> >>>>> Some (minor) discussion of this idea in -wizards earli= er today<br> >>>>> starting<br> >>>>> near near "09:50" (apologies for having no a= nchor links):<br> >>>>> <a href=3D"http://gnusha.org/bitcoin-wizards/2015-11-2= 4.log" rel=3D"noreferrer" target=3D"_blank">http://gnusha.org/bitcoin-wizar= ds/2015-11-24.log</a><br> >>>>><br> >>>>> - Bryan<br> >>>>> <a href=3D"http://heybryan.org/" rel=3D"noreferrer" ta= rget=3D"_blank">http://heybryan.org/</a><br> >>>>> <a href=3D"tel:1%20512%20203%200507" value=3D"+1512203= 0507">1 512 203 0507</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> bitcoin-dev mailing list<br> >>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= g">bitcoin-dev@lists.linuxfoundation.org</a><br> >>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/l= istinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.lin= uxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> >>>>><br> >>>>><br> >>>><br> >>>><br> >>>> --<br> >>>> I like to provide some work at no charge to prove my value= . Do you need<br> >>>> a<br> >>>> techie?<br> >>>> I own Litmocracy <<a href=3D"http://www.litmocracy.com"= rel=3D"noreferrer" target=3D"_blank">http://www.litmocracy.com</a>> and= Meme Racing<br> >>>> <<a href=3D"http://www.memeracing.net" rel=3D"noreferre= r" target=3D"_blank">http://www.memeracing.net</a>> (in alpha).<br> >>>> I'm the webmaster for The Voluntaryist <<a href=3D"= http://www.voluntaryist.com" rel=3D"noreferrer" target=3D"_blank">http://ww= w.voluntaryist.com</a>><br> >>> which<br> >>>> now accepts Bitcoin.<br> >>>> I also code for The Dollar Vigilante <<a href=3D"http:/= /dollarvigilante.com/" rel=3D"noreferrer" target=3D"_blank">http://dollarvi= gilante.com/</a>>.<br> >>>> "He ought to find it more profitable to play by the r= ules" - Satoshi<br> >>>> Nakamoto<br> >>>><br> >>> _______________________________________________<br> >>> bitcoin-dev mailing list<br> >>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= in-dev@lists.linuxfoundation.org</a><br> >>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/= bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev</a><br> >>><br> >><br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev</a><br> <br> -----BEGIN PGP SIGNATURE-----<br> Version: GnuPG v2.0.22 (GNU/Linux)<br> <br> iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1<br> DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx<br> 946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd<br> fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG<br> Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI<br> TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI<br> 8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o<br> ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm<br> /h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU<br> xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz<br> 2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW<br> E6sERK8uG8S3KdBSVQ7K<br> =3D1xdi<br> -----END PGP SIGNATURE-----<br> <br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --089e0168199e1ae73e05255f49d6--