From: Rusty Russell <rusty@rustcorp•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: John Barboza <johnbarboza@gmail•com>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)
Date: Mon, 19 Oct 2020 11:19:17 +1030 [thread overview]
Message-ID: <877drn2g6q.fsf@rustcorp.com.au> (raw)
In-Reply-To: <sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
Pieter Wuille <bitcoin-dev@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.
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).
> Does anyone have an up-to-date overview of where to-future-witness sending
> is supported? I know Bitcoin Core does.
Anecdata: c-lightning doesn't allow withdraw to segwit > 0. It seems
that the contributor John Barboza (CC'd) assumed that future versions
should be invalid:
if (bip173) {
bool witness_ok = false;
if (witness_version == 0 && (witness_program_len == 20 ||
witness_program_len == 32)) {
witness_ok = true;
}
/* Insert other witness versions here. */
>> Deferring a hard decision is not useful unless we expect things to be
>> easier in future, and I only see it getting harder as time passes and
>> userbases grow.
>
> Possibly, but in the past I think there has existed a pattern where adoption
> of new technology is at least partially based on certain infrastructure
> and codebases going out of business and/or being replaced with newer ones,
> rather than improvements to existing ones.
>
> If that effect is significant, option 1 may be preferable: it means less
> compatibility issues in the short term, and longer term all that may be
> required is fixing the spec, and waiting long enough for old/unmaintained code
> to be replaced.
Hmm, I'd rather cleanly break zombie infra, since they're exactly the
kind that won't/cant fix the case where someone trailing-typos?
> 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.
>> The good news it that the change is fairly simple and the reference
>> implementations are widely used so change is not actually that hard
>> once the decision is made.
>
> Indeed. Whatever observations we had about adoption of base58 -> bech32 may not
> apply because the change to a different checksum is fairly trivial compared to
> that. Still, presence of production codebases that just don't update at all
> may complicate this.
>
>> > Hopefully by the time we want to use segwit v2, most software will have
>> > implemented length limits and so we won't need any additional consensus
>> > restrictions from then on forward.
>>
>> If we are prepared to commit to restrictions on future addresses.
>>
>> We don't know enough to do that, however, so I'm reluctant; I worry that
>> a future scheme where we could save (e.g.) 2 bytes will impractical due
>> to our encoding restrictions, resulting in unnecessary onchain bloat.
>
> I'm opposed to consensus-invalidating certain length/version combinations, if
> that's what you're suggesting, and I don't think there is a need for it.
This *seems* to leave the option of later removing size restrictions,
but I think this is an illusion. Upgrading will only get harder over
time: we would instead opt for some kind of backward compatiblity hack
(i.e. 33 byte address, but you can optionally add 3 zero pad bytes)
which *will* have consensus effect.
> 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 :)
Thanks!
Rusty.
next prev parent reply other threads:[~2020-10-19 1:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 0:21 Rusty Russell
2020-10-08 14:59 ` David A. Harding
2020-10-08 15:21 ` Russell O'Connor
2020-10-15 1:40 ` Rusty Russell
2020-10-16 21:09 ` Pieter Wuille
2020-10-19 0:49 ` Rusty Russell [this message]
2020-10-19 22:55 ` Pieter Wuille
2020-10-20 0:42 ` Rusty Russell
2020-10-20 3:31 ` Rusty Russell
2020-10-20 9:21 ` Riccardo Casatta
2020-10-20 10:29 ` David A. Harding
2020-10-20 20:12 ` Pieter Wuille
2020-10-20 23:52 ` Mike Schmidt
2020-10-21 4:51 ` Rusty Russell
2020-11-06 19:49 ` Mike Schmidt
2020-12-05 23:10 ` Pieter Wuille
2020-12-06 13:04 ` David A. Harding
2020-12-06 20:43 ` Pieter Wuille
2020-12-08 17:39 ` Ryan Grant
2020-12-18 2:02 ` Pieter Wuille
2020-10-21 3:05 ` ZmnSCPxj
2020-10-21 4:39 ` Rusty Russell
2020-10-28 0:20 ` Pieter Wuille
2020-12-05 22:59 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877drn2g6q.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=johnbarboza@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox