Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-19 📝 Original message:On Sunday, October 18, ...
📅 Original date posted:2020-10-19
📝 Original message:On Sunday, October 18, 2020 5:49 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Pieter Wuille bitcoin-dev at wuille.net writes:
>
> > Today, no witness v1 receivers exist. So it seems to me the only question
> > is what software/infrastructure exist that supports sending to witness v1,
> > and whether they (and their userbase) are more or less likely to upgrade
> > before receivers appear than those that don't.
> > Clearly if only actively developed software currently supports sending to
> > v1 right now, then the question of forward compatibility is moot, and I'd
> > agree the cleanliness of option 2 is preferable.
>
> If software supports v1 today and doesn't get upgraded, and we persue
> option 1 then a trailing typo can make trouble. Not directly lose money
> (since the tx won't get propagated), but for most systems (e.g. hosted
> wallets) someone has to go in and figure out the error and fix it up.
It depends. As is, they'd be relayed even as sending to future witness versions
or lengths is standard. If option 1 is chosen there may be reasons to add
safeguards using relay policy, though.
> Option 2 means they're likely to fix their systems the first time
> someone tries a v1 send, not the first time someone makes a trailing
> typo (which might be years).
Possibly, but it's also possible that it won't get fixed at all, and instead
receiver software just has to wait a few years longer before being able to start
giving out v1 addresses and have a reasonable chance the sender supports it.
You're right though that protecting old sender software from being protected
against the insertion bug is a good argument in favor of Option 2.
Strictly speaking it also has an issue, as the error detection properties aren't
guaranteed for new-scheme-address + intended-detected-error interpreted as
old-scheme-address (in particular, you can make 4 substitution errors in
a new-scheme address and have it be a valid old-scheme address). This is much
less of an issue than the insertion bug that remains present with Option 1 in
old senders.
> > As for how long: new witness version/length combinations are only rarely needed,
> > and there are 14 length=32 ones left to pick. We'll likely want to use those
> > first anyway, as it's the cheapest option with 128-bit collision resistance.
> > Assuming future constructions have something like BIP341's leaf versioning, new
> > witness version/length combinations are only required for:
> >
> > - Changes to the commitment structure of script execution (e.g. Graftroot,
> > different hash function for Merkle trees, ...)
> >
> > - Upgrades to new signing cryptography (EC curve change, PQC, ...).
> > - Changes to signatures outside of a commitment structure (e.g. new sighash
> > modes for the keypath in BIP341, or cross-input aggregation for them).
> >
> >
> > and in general, not for things like new script opcodes, or even for fairly
> > invasive redesigns of the script language itself.
>
> Hmm, good point. These can all be done with version bumps.
>
> The only use for extra bytes I can see is per-UTXO flags, but even then
> I can't see why you'd need to know them until their spent (in which case
> you stash the flag in the input, not the output).
>
> And fewer bytes seems bad for fungibility, since multisig would be
> dangerous.
>
> But the future keeps surprising me, so I'm still hesitant.
Of course, our thinking here may change significantly over time - still, I expect
it'll be years before something other than 32-byte addresses is desired.
> > TL;DR: what codebases/services/infrastructure exists today that supports
> > sending to witness v1 BIP173 addresses?
>
> OK, time to waste some money!
>
> Can you provide a mainnet v1 address, and I'll try to spam it from as
> many things as I can find. If we're really lucky, you can collect it
> post-fork and donate it to charity. Or a miner can steal it pre-fork :)
Here is a BIP341 witness v1 address, corresponding to just the generator as
inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP):
bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY ptwy6lm87hf5ss52r5n8
Cheers,
--
Pieter
Published at
2023-06-07 18:27:23Event JSON
{
"id": "2a010395c8485d5f2a1b80c8d6b0e81338692d900fd9d3451729d2bf12d34ae1",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686162443,
"kind": 1,
"tags": [
[
"e",
"4783c6c909b78f666abf4f62da363dc4a252b6e15f69428bf595d553895a198d",
"",
"root"
],
[
"e",
"52cef27978ed66006890c532de956577ccbbb4992f2424da4a47fc0ff8ac4295",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2020-10-19\n📝 Original message:On Sunday, October 18, 2020 5:49 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Pieter Wuille bitcoin-dev at wuille.net writes:\n\u003e\n\u003e \u003e Today, no witness v1 receivers exist. So it seems to me the only question\n\u003e \u003e is what software/infrastructure exist that supports sending to witness v1,\n\u003e \u003e and whether they (and their userbase) are more or less likely to upgrade\n\u003e \u003e before receivers appear than those that don't.\n\u003e \u003e Clearly if only actively developed software currently supports sending to\n\u003e \u003e v1 right now, then the question of forward compatibility is moot, and I'd\n\u003e \u003e agree the cleanliness of option 2 is preferable.\n\u003e\n\u003e If software supports v1 today and doesn't get upgraded, and we persue\n\u003e option 1 then a trailing typo can make trouble. Not directly lose money\n\u003e (since the tx won't get propagated), but for most systems (e.g. hosted\n\u003e wallets) someone has to go in and figure out the error and fix it up.\n\nIt depends. As is, they'd be relayed even as sending to future witness versions\nor lengths is standard. If option 1 is chosen there may be reasons to add\nsafeguards using relay policy, though.\n\n\u003e Option 2 means they're likely to fix their systems the first time\n\u003e someone tries a v1 send, not the first time someone makes a trailing\n\u003e typo (which might be years).\n\nPossibly, but it's also possible that it won't get fixed at all, and instead\nreceiver software just has to wait a few years longer before being able to start\ngiving out v1 addresses and have a reasonable chance the sender supports it.\n\nYou're right though that protecting old sender software from being protected\nagainst the insertion bug is a good argument in favor of Option 2.\n\nStrictly speaking it also has an issue, as the error detection properties aren't\nguaranteed for new-scheme-address + intended-detected-error interpreted as\nold-scheme-address (in particular, you can make 4 substitution errors in\na new-scheme address and have it be a valid old-scheme address). This is much\nless of an issue than the insertion bug that remains present with Option 1 in\nold senders.\n\n\u003e \u003e As for how long: new witness version/length combinations are only rarely needed,\n\u003e \u003e and there are 14 length=32 ones left to pick. We'll likely want to use those\n\u003e \u003e first anyway, as it's the cheapest option with 128-bit collision resistance.\n\u003e \u003e Assuming future constructions have something like BIP341's leaf versioning, new\n\u003e \u003e witness version/length combinations are only required for:\n\u003e \u003e\n\u003e \u003e - Changes to the commitment structure of script execution (e.g. Graftroot,\n\u003e \u003e different hash function for Merkle trees, ...)\n\u003e \u003e\n\u003e \u003e - Upgrades to new signing cryptography (EC curve change, PQC, ...).\n\u003e \u003e - Changes to signatures outside of a commitment structure (e.g. new sighash\n\u003e \u003e modes for the keypath in BIP341, or cross-input aggregation for them).\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e and in general, not for things like new script opcodes, or even for fairly\n\u003e \u003e invasive redesigns of the script language itself.\n\u003e\n\u003e Hmm, good point. These can all be done with version bumps.\n\u003e\n\u003e The only use for extra bytes I can see is per-UTXO flags, but even then\n\u003e I can't see why you'd need to know them until their spent (in which case\n\u003e you stash the flag in the input, not the output).\n\u003e\n\u003e And fewer bytes seems bad for fungibility, since multisig would be\n\u003e dangerous.\n\u003e\n\u003e But the future keeps surprising me, so I'm still hesitant.\n\nOf course, our thinking here may change significantly over time - still, I expect\nit'll be years before something other than 32-byte addresses is desired.\n\n\u003e \u003e TL;DR: what codebases/services/infrastructure exists today that supports\n\u003e \u003e sending to witness v1 BIP173 addresses?\n\u003e\n\u003e OK, time to waste some money!\n\u003e\n\u003e Can you provide a mainnet v1 address, and I'll try to spam it from as\n\u003e many things as I can find. If we're really lucky, you can collect it\n\u003e post-fork and donate it to charity. Or a miner can steal it pre-fork :)\n\nHere is a BIP341 witness v1 address, corresponding to just the generator as\ninner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP):\n\nbc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY ptwy6lm87hf5ss52r5n8\n\n\nCheers,\n\n--\nPieter",
"sig": "d21d735471f20e52af674e0b12471b889d2cbdeddeea38cf44e3e66b56ae9965ab8ed6d6110e5b657f739de447a3f56358e9562e2f3fb7120414347e02628013"
}