📅 Original date posted:2015-11-24
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org> wrote:
> >
> >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> >> bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/0140731a/attachment-0001.html>;
Jannes Faber [ARCHIVE] /
npub17p…dwqxx
2023-06-07 19:45:13
in reply to nevent1q…pzgc
Author Public Key
npub17ptfn7hft8a4s25t6449tdsnht7krskz8xsqh302vma0pjm6925qcdwqxxPublished at
2023-06-07 19:45:13Event JSON
{
"id": "31b72b08759b443fc9a0fa6725d3580a49ec1e0d42aabd16d3bd871dd6a6bbea",
"pubkey": "f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8",
"created_at": 1686159913,
"kind": 1,
"tags": [
[
"e",
"bf4809cae02e8295ff1b511081cddea17791dccae1a87a2654644d42bcc4eb89",
"",
"root"
],
[
"e",
"a2e97efc71237445114e598791c9d330616849d5e81f991f1d820e69f38062a1",
"",
"reply"
],
[
"p",
"3b5311200328974edeaa105b1a8f60d243e653cc63b6bb29f61dc696e04189ed"
]
],
"content": "📅 Original date posted:2015-11-24\n📝 Original message:Few issues I can think of:\n\n1. In its basic form this encourages address reuse. Unless the wildcard can\nbe constructed such that it can match a whole branch of an HD wallet.\nAlthough I guess that would tie all those addresses together making HD moot\nto begin with.\n\n2. Sounds pretty dangerous during reorgs. Maybe such a transaction should\ninclude a block height which indicates the maximum block that any utxo can\nmatch. With the requirement that the specified block height is at least 100\nblocks in the past. Maybe add a minimum block height as well to prevent\nunnecessary scanning (with the requirement that at least one utxo must be\nin that minimum block).\n\n3. Seems like a nice way to the reduce utxo set. But hard to say how\neffective it would really be.\nOn 25 Nov 2015 12:48 a.m., \"Chris Priest via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e This idea could be applied by having the wildcard signature apply to all\n\u003e \u003e UTXOs that are of a standard form and paid to a particular address, and\n\u003e be\n\u003e \u003e a signature of some kind of message to that effect.\n\u003e\n\u003e I think this is true. Not *all* transactions will be able to match the\n\u003e wildcard. For instance if someone sent some crazy smart contract tx to\n\u003e your address, the script associated with that tx will be such that it\n\u003e will not apply to the wildcard. Most \"vanilla\" utxos that I've seen\n\u003e have the formula: OP_DUP OP_HASH160 [a hash corresponding to your\n\u003e address] OP_EQUALVERIFY OP_CHECKSIG\". Just UTXOs in that form could\n\u003e apply to the wildcard.\n\u003e\n\u003e On 11/24/15, Dave Scotese via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e What is required to spend bitcoin is that input be provided to the UTXO\n\u003e \u003e script that causes it to return true. What Chris is proposing breaks the\n\u003e \u003e programmatic nature of the requirement, replacing it with a requirement\n\u003e \u003e that the secret be known. Granted, the secret is the only requirement in\n\u003e \u003e most cases, but there is no built-in assumption that the script always\n\u003e \u003e requires only that secret.\n\u003e \u003e\n\u003e \u003e This idea could be applied by having the wildcard signature apply to all\n\u003e \u003e UTXOs that are of a standard form and paid to a particular address, and\n\u003e be\n\u003e \u003e a signature of some kind of message to that effect. I imagine the cost\n\u003e of\n\u003e \u003e re-scanning the UTXO set to find them all would justify a special extra\n\u003e \u003e mining fee for any transaction that used this opcode.\n\u003e \u003e\n\u003e \u003e Please be blunt about any of my own misunderstandings that this email\n\u003e makes\n\u003e \u003e clear.\n\u003e \u003e\n\u003e \u003e On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev \u003c\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev \u003c\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e **OP_CHECKWILDCARDSIGVERIFY**\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Some (minor) discussion of this idea in -wizards earlier today starting\n\u003e \u003e\u003e near near \"09:50\" (apologies for having no anchor links):\n\u003e \u003e\u003e http://gnusha.org/bitcoin-wizards/2015-11-24.log\n\u003e \u003e\u003e\n\u003e \u003e\u003e - Bryan\n\u003e \u003e\u003e http://heybryan.org/\n\u003e \u003e\u003e 1 512 203 0507\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e I like to provide some work at no charge to prove my value. Do you need a\n\u003e \u003e techie?\n\u003e \u003e I own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003e \u003e \u003chttp://www.memeracing.net\u003e (in alpha).\n\u003e \u003e I'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e\n\u003e which\n\u003e \u003e now accepts Bitcoin.\n\u003e \u003e I also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e \u003e \"He ought to find it more profitable to play by the rules\" - Satoshi\n\u003e \u003e Nakamoto\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/0140731a/attachment-0001.html\u003e",
"sig": "9b53fd9be2f4df208c29f510ea26c7516da8a5bd6979abd9bac5bcf8396457279060957dcd5ca2fb38d578c66ea3efaa95e6d83001a241e005130dc9b0594fe7"
}