📅 Original date posted:2015-11-24
📝 Original message: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 at 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 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
>>
>
Chris Priest [ARCHIVE] /
npub18d…xccej
2023-06-07 17:45:14
in reply to nevent1q…nf9l
Author Public Key
npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccejPublished at
2023-06-07 17:45:14Event JSON
{
"id": "62c5dfa2c6b9cbc7b9c8a8e0f73d052b931c5823959243a8fcac3e77d89da8dc",
"pubkey": "3b5311200328974edeaa105b1a8f60d243e653cc63b6bb29f61dc696e04189ed",
"created_at": 1686159914,
"kind": 1,
"tags": [
[
"e",
"bf4809cae02e8295ff1b511081cddea17791dccae1a87a2654644d42bcc4eb89",
"",
"root"
],
[
"e",
"31b72b08759b443fc9a0fa6725d3580a49ec1e0d42aabd16d3bd871dd6a6bbea",
"",
"reply"
],
[
"p",
"f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8"
]
],
"content": "📅 Original date posted:2015-11-24\n📝 Original message:1. Technically is it promoting address reuse, but in this case, I\nthink it's OK. The primary purpose of a coalescing transaction is to\nclear out *all* funds associated with one address and send them to\nanother address (belonging to the same owner). If you coalesce the\ninputs to the same address over and over again, you an do that, but\nyou'll run the risk of leaking your private key.\n\n2. I see these transactions being broadcast in the background when the\nuser is not planning on sending or receiving any payments. By the time\nthe wallet user wants to spend funds from the address, the coalescing\ntransaction should be sufficiently deep enough in the blockchain to\navoid re-org tomfoolery. Exchanges and payment processors who take in\npayments around the clock will probably never use these transactions,\nat least not on \"live\" addresses.\n\n3. I never thought of that, but thats a benefit too!\n\nOn 11/24/15, Jannes Faber via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Few issues I can think of:\n\u003e\n\u003e 1. In its basic form this encourages address reuse. Unless the wildcard can\n\u003e be constructed such that it can match a whole branch of an HD wallet.\n\u003e Although I guess that would tie all those addresses together making HD moot\n\u003e to begin with.\n\u003e\n\u003e 2. Sounds pretty dangerous during reorgs. Maybe such a transaction should\n\u003e include a block height which indicates the maximum block that any utxo can\n\u003e match. With the requirement that the specified block height is at least 100\n\u003e blocks in the past. Maybe add a minimum block height as well to prevent\n\u003e unnecessary scanning (with the requirement that at least one utxo must be\n\u003e in that minimum block).\n\u003e\n\u003e 3. Seems like a nice way to the reduce utxo set. But hard to say how\n\u003e effective it would really be.\n\u003e On 25 Nov 2015 12:48 a.m., \"Chris Priest via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e \u003e This idea could be applied by having the wildcard signature apply to\n\u003e\u003e \u003e all\n\u003e\u003e \u003e UTXOs that are of a standard form and paid to a particular address, and\n\u003e\u003e be\n\u003e\u003e \u003e a signature of some kind of message to that effect.\n\u003e\u003e\n\u003e\u003e I think this is true. Not *all* transactions will be able to match the\n\u003e\u003e wildcard. For instance if someone sent some crazy smart contract tx to\n\u003e\u003e your address, the script associated with that tx will be such that it\n\u003e\u003e will not apply to the wildcard. Most \"vanilla\" utxos that I've seen\n\u003e\u003e have the formula: OP_DUP OP_HASH160 [a hash corresponding to your\n\u003e\u003e address] OP_EQUALVERIFY OP_CHECKSIG\". Just UTXOs in that form could\n\u003e\u003e apply to the wildcard.\n\u003e\u003e\n\u003e\u003e On 11/24/15, Dave Scotese via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e What is required to spend bitcoin is that input be provided to the UTXO\n\u003e\u003e \u003e script that causes it to return true. What Chris is proposing breaks\n\u003e\u003e \u003e the\n\u003e\u003e \u003e programmatic nature of the requirement, replacing it with a requirement\n\u003e\u003e \u003e that the secret be known. Granted, the secret is the only requirement\n\u003e\u003e \u003e in\n\u003e\u003e \u003e most cases, but there is no built-in assumption that the script always\n\u003e\u003e \u003e requires only that secret.\n\u003e\u003e \u003e\n\u003e\u003e \u003e This idea could be applied by having the wildcard signature apply to\n\u003e\u003e \u003e all\n\u003e\u003e \u003e UTXOs that are of a standard form and paid to a particular address, and\n\u003e\u003e be\n\u003e\u003e \u003e a signature of some kind of message to that effect. I imagine the cost\n\u003e\u003e of\n\u003e\u003e \u003e re-scanning the UTXO set to find them all would justify a special extra\n\u003e\u003e \u003e mining fee for any transaction that used this opcode.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Please be blunt about any of my own misunderstandings that this email\n\u003e\u003e makes\n\u003e\u003e \u003e clear.\n\u003e\u003e \u003e\n\u003e\u003e \u003e On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop 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 On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev \u003c\n\u003e\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\u003e **OP_CHECKWILDCARDSIGVERIFY**\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Some (minor) discussion of this idea in -wizards earlier today\n\u003e\u003e \u003e\u003e starting\n\u003e\u003e \u003e\u003e near near \"09:50\" (apologies for having no anchor links):\n\u003e\u003e \u003e\u003e http://gnusha.org/bitcoin-wizards/2015-11-24.log\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e - Bryan\n\u003e\u003e \u003e\u003e http://heybryan.org/\n\u003e\u003e \u003e\u003e 1 512 203 0507\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e --\n\u003e\u003e \u003e I like to provide some work at no charge to prove my value. Do you need\n\u003e\u003e \u003e a\n\u003e\u003e \u003e techie?\n\u003e\u003e \u003e I own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003e\u003e \u003e \u003chttp://www.memeracing.net\u003e (in alpha).\n\u003e\u003e \u003e I'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e\n\u003e\u003e which\n\u003e\u003e \u003e now accepts Bitcoin.\n\u003e\u003e \u003e I also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e\u003e \u003e \"He ought to find it more profitable to play by the rules\" - Satoshi\n\u003e\u003e \u003e Nakamoto\n\u003e\u003e \u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e",
"sig": "ff2c0a5ada149df73f8f072116e6cc4dc098eec887ff572c6874990c3e19f197e96b006591572493c3e063682bea8d65e1519ea163a8a25dd6e714385a4cdd0c"
}