path: root/1f/815e31faac46684decb7651e917102fbd08c7c

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">&gt; 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, &quot;Erik via bitcoin-=
dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;t bother the person sending th=
e<br>
transactions. What you see is the transactions to the address you&#39;ve<br=
>
agreed sum up to the amount you asked for. When you later try to spend<br>
it, you can&#39;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&#39;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&#39;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&#39;t created earlier than that. Also makes<=
br>
the wildcard TX invalid if that block isn&#39;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>
&gt; 1. Technically is it promoting address reuse, but in this case, I<br>
&gt; think it&#39;s OK. The primary purpose of a coalescing transaction is =
to<br>
&gt; clear out *all* funds associated with one address and send them to<br>
&gt; another address (belonging to the same owner). If you coalesce the<br>
&gt; inputs to the same address over and over again, you an do that, but<br=
>
&gt; you&#39;ll run the risk of leaking your private key.<br>
&gt;<br>
&gt; 2. I see these transactions being broadcast in the background when the=
<br>
&gt; user is not planning on sending or receiving any payments. By the time=
<br>
&gt; the wallet user wants to spend funds from the address, the coalescing<=
br>
&gt; transaction should be sufficiently deep enough in the blockchain to<br=
>
&gt; avoid re-org tomfoolery. Exchanges and payment processors who take in<=
br>
&gt; payments around the clock will probably never use these transactions,<=
br>
&gt; at least not on &quot;live&quot; addresses.<br>
&gt;<br>
&gt; 3. I never thought of that, but thats a benefit too!<br>
&gt;<br>
&gt; On 11/24/15, Jannes Faber via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; Few issues I can think of:<br>
&gt;&gt;<br>
&gt;&gt; 1. In its basic form this encourages address reuse. Unless the<br>
wildcard can<br>
&gt;&gt; be constructed such that it can match a whole branch of an HD=C2=
=A0 wallet.<br>
&gt;&gt; Although I guess that would tie all those addresses together makin=
g<br>
HD moot<br>
&gt;&gt; to begin with.<br>
&gt;&gt;<br>
&gt;&gt; 2. Sounds pretty dangerous during reorgs. Maybe such a transaction=
 should<br>
&gt;&gt; include a block height which indicates the maximum block that any<=
br>
utxo can<br>
&gt;&gt; match. With the requirement that the specified block height is at<=
br>
least 100<br>
&gt;&gt; blocks in the past. Maybe add a minimum block height as well to pr=
event<br>
&gt;&gt; unnecessary scanning (with the requirement that at least one utxo =
must be<br>
&gt;&gt; in that minimum block).<br>
&gt;&gt;<br>
&gt;&gt; 3. Seems like a nice way to the reduce utxo set. But hard to say h=
ow<br>
&gt;&gt; effective it would really be.<br>
&gt;&gt; On 25 Nov 2015 12:48 a.m., &quot;Chris Priest via bitcoin-dev&quot=
; &lt;<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;&gt; This idea could be applied by having the wildcard signatur=
e apply to<br>
&gt;&gt;&gt;&gt; all<br>
&gt;&gt;&gt;&gt; UTXOs that are of a standard form and paid to a particular=
 address, and<br>
&gt;&gt;&gt; be<br>
&gt;&gt;&gt;&gt; a signature of some kind of message to that effect.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think this is true. Not *all* transactions will be able to m=
atch the<br>
&gt;&gt;&gt; wildcard. For instance if someone sent some crazy smart contra=
ct tx to<br>
&gt;&gt;&gt; your address, the script associated with that tx will be such =
that it<br>
&gt;&gt;&gt; will not apply to the wildcard. Most &quot;vanilla&quot; utxos=
 that I&#39;ve seen<br>
&gt;&gt;&gt; have the formula: OP_DUP OP_HASH160 [a hash corresponding to y=
our<br>
&gt;&gt;&gt; address] OP_EQUALVERIFY OP_CHECKSIG&quot;. Just UTXOs in that =
form could<br>
&gt;&gt;&gt; apply to the wildcard.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 11/24/15, Dave Scotese via bitcoin-dev<br>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; What is required to spend bitcoin is that input be provide=
d to the UTXO<br>
&gt;&gt;&gt;&gt; script that causes it to return true.=C2=A0 What Chris is =
proposing breaks<br>
&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt; programmatic nature of the requirement, replacing it with =
a requirement<br>
&gt;&gt;&gt;&gt; that the secret be known.=C2=A0 Granted, the secret is the=
 only requirement<br>
&gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt;&gt; most cases, but there is no built-in assumption that the s=
cript always<br>
&gt;&gt;&gt;&gt; requires only that secret.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This idea could be applied by having the wildcard signatur=
e apply to<br>
&gt;&gt;&gt;&gt; all<br>
&gt;&gt;&gt;&gt; UTXOs that are of a standard form and paid to a particular=
 address, and<br>
&gt;&gt;&gt; be<br>
&gt;&gt;&gt;&gt; a signature of some kind of message to that effect.=C2=A0 =
I imagine the cost<br>
&gt;&gt;&gt; of<br>
&gt;&gt;&gt;&gt; re-scanning the UTXO set to find them all would justify a =
special extra<br>
&gt;&gt;&gt;&gt; mining fee for any transaction that used this opcode.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Please be blunt about any of my own misunderstandings that=
 this email<br>
&gt;&gt;&gt; makes<br>
&gt;&gt;&gt;&gt; clear.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-=
dev &lt;<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bit=
coin-dev &lt;<br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; **OP_CHECKWILDCARDSIGVERIFY**<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Some (minor) discussion of this idea in -wizards earli=
er today<br>
&gt;&gt;&gt;&gt;&gt; starting<br>
&gt;&gt;&gt;&gt;&gt; near near &quot;09:50&quot; (apologies for having no a=
nchor links):<br>
&gt;&gt;&gt;&gt;&gt; <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>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; - Bryan<br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"http://heybryan.org/" rel=3D"noreferrer" ta=
rget=3D"_blank">http://heybryan.org/</a><br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"tel:1%20512%20203%200507" value=3D"+1512203=
0507">1 512 203 0507</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt;&gt; <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>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; I like to provide some work at no charge to prove my value=
. Do you need<br>
&gt;&gt;&gt;&gt; a<br>
&gt;&gt;&gt;&gt; techie?<br>
&gt;&gt;&gt;&gt; I own Litmocracy &lt;<a href=3D"http://www.litmocracy.com"=
 rel=3D"noreferrer" target=3D"_blank">http://www.litmocracy.com</a>&gt; and=
 Meme Racing<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"http://www.memeracing.net" rel=3D"noreferre=
r" target=3D"_blank">http://www.memeracing.net</a>&gt; (in alpha).<br>
&gt;&gt;&gt;&gt; I&#39;m the webmaster for The Voluntaryist &lt;<a href=3D"=
http://www.voluntaryist.com" rel=3D"noreferrer" target=3D"_blank">http://ww=
w.voluntaryist.com</a>&gt;<br>
&gt;&gt;&gt; which<br>
&gt;&gt;&gt;&gt; now accepts Bitcoin.<br>
&gt;&gt;&gt;&gt; I also code for The Dollar Vigilante &lt;<a href=3D"http:/=
/dollarvigilante.com/" rel=3D"noreferrer" target=3D"_blank">http://dollarvi=
gilante.com/</a>&gt;.<br>
&gt;&gt;&gt;&gt; &quot;He ought to find it more profitable to play by the r=
ules&quot; - Satoshi<br>
&gt;&gt;&gt;&gt; Nakamoto<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt; <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>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <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--