Jannes Faber [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-24 📝 Original message:Few issues I can think of: ...
📅 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>;
📝 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>;