path: root/49/0619d472940f0a35f3a826f74893b9efd0d907

Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DBCB71BB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 17:03:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com
	[209.85.214.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C167163
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 17:03:33 +0000 (UTC)
Received: by obbww6 with SMTP id ww6so43519577obb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 09:03:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=smSHIkotmk3B+w2pfEsPM6A64YfPzi24QZTtE5gKCZ8=;
	b=kTPf90FDCx34fkhi62yR16pVjOoWzdgWASDsGJOf+IN+cxeKSeoOl6s+Jozkw2anpt
	nquKbcx6V2M9EatXPV5o1bA5LEcF1B4T6SKJvxxscjSFUaLBFVP3nurjzxmtdTvbCW+x
	2jTV7i2JQWUUR4mjLJKfxDjMqPXOgnmbi4AMMLgSbEB+wXxYtpYOCLluaFKoKOCGu7Zi
	eDAvQUc+u00Ow8/2FkCxsh92RZwh1+M+1guZeEFQdSpXvZ/Tz2omhMo+LjR/XY9ITwym
	dD1+UiAsCyUVN3PPvHjzUsRuBkYmGq1Guee6+d32d6L8AO0Ugkhb+c39uOCLd16wRD/t
	TA3g==
MIME-Version: 1.0
X-Received: by 10.60.39.233 with SMTP id s9mr24714887oek.57.1448471012940;
	Wed, 25 Nov 2015 09:03:32 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.16.39 with HTTP; Wed, 25 Nov 2015 09:03:32 -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:03:32 -0800
X-Google-Sender-Auth: 2OOW9M4c6sOp245ekmIjnxE6V0c
Message-ID: <CAGLBAhdeejxXJqTFo5-Sch0dFbX8DNfsZ3eg7i80pDyH6juuHg@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Erik <erik.fors@startmail.com>
Content-Type: multipart/alternative; boundary=089e013c632a31a5a5052560703e
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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 17:06:36 +0000
Cc: Bitcoin Dev <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 17:03:36 -0000

--089e013c632a31a5a5052560703e
Content-Type: text/plain; charset=UTF-8

The message could specify:
{ stib: 0x01,
  TxnCount: (# of entries in the Indexes array)
  Indexes: [{BLK: Block#,Txns:[TxIndex,TxIndex,...]},{BLK:
Block#,Txns:[...]}],
  NewUTXO: (The script that will spend these coins)
}
*stib *is a Script Template Index Bitfield: Must (currently) be the byte
0x01, to indicate the "vanilla" script Chris identified.  If other scripts
appear to fit the bill in the future, they can be assigned to other bits.
*Indexes *is a list of pairs that identify a block by its height and a list
of indexes into the block.  This puts the onus on the transactor to
identify all the inputs instead of requiring the miner to scan for them.

If block heights and transaction indexes are 32-bit integers, this reduces
the per-input size cost by at least 100 bytes, if I did my math right.


On Wed, Nov 25, 2015 at 6: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
>



-- 
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

--089e013c632a31a5a5052560703e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>The message could specify:<br></div><div>{ stib:=
 0x01,<br></div><div>=C2=A0 TxnCount: (# of entries in the Indexes array)<b=
r></div><div>=C2=A0 Indexes: [{BLK: Block#,Txns:[TxIndex,TxIndex,...]},{BLK=
: Block#,Txns:[...]}],<br></div><div>=C2=A0 NewUTXO: (The script that will =
spend these coins)<br>}<br></div><b>stib </b>is a Script Template Index Bit=
field: Must (currently) be the byte 0x01, to indicate the &quot;vanilla&quo=
t; script Chris identified.=C2=A0 If other scripts appear to fit the bill i=
n the future, they can be assigned to other bits.<br></div><div><b>Indexes =
</b>is a list of pairs that identify a block by its height and a list of in=
dexes into the block.=C2=A0 This puts the onus on the transactor to identif=
y all the inputs instead of requiring the miner to scan for them.<br><br></=
div><div>If block heights and transaction indexes are 32-bit integers, this=
 reduces the per-input size cost by at least 100 bytes, if I did my math ri=
ght.<br></div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, Nov 25, 2015 at 6:16 AM, Erik via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc 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>
<div><div class=3D"h5"><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>
</div></div>-----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>
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work at no cha=
rge to prove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"htt=
p://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"htt=
p://www.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I=
&#39;m the webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"=
_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I also code for =
<a href=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigila=
nte</a>.<br>&quot;He ought to find it more profitable to play by the rules&=
quot; - Satoshi Nakamoto</div></div>
</div>

--089e013c632a31a5a5052560703e--