From: Johnson Lau <jl2012@xbt•hk>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit v2
Date: Thu, 27 Apr 2017 03:31:38 +0800 [thread overview]
Message-ID: <06E90C6D-8B4C-40A7-8807-8811A27AE401@xbt.hk> (raw)
In-Reply-To: <201704202028.53113.luke@dashjr.org>
I prefer not to do anything that requires pools software upgrade or wallet upgrade. So I prefer to keep the dummy marker, and not change the commitment structure as suggested by another post.
For your second suggestion, I think we should keep scriptSig empty as that should be obsoleted. If you want to put something in scriptSig, you should put it in witness instead.
Maybe we could restrict witness to IsPushOnly() scriptPubKey, so miners can’t put garbage to legacy txs. But I think relaxing the witness program size to 73 bytes is enough for any purpose.
> On 21 Apr 2017, at 04:28, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Since BIP 141's version bit assignment will timeout soon, and needing renewal,
> I was thinking it might make sense to make some minor tweaks to the spec for
> the next deployment. These aren't critical, so it's perfectly fine if BIP 141
> activates as-is (potentially with BIP 148), but IMO would be an improvement if
> a new deployment (non-BIP148 UASF and/or new versionbit) is needed.
>
> 1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity
> with incomplete zero-input transactions, which has been a source of confusion
> for raw transaction APIs. 0xFF would normally indicate a >32-bit input count,
> which is impossible right now (it'd require a >=158 GB transaction) and
> unlikely to ever be useful.
>
> 2. Relax the consensus rules on when witness data is allowed for an input.
> Currently, it is only allowed when the scriptSig is null, and the scriptPubKey
> being spent matches a very specific pattern. It is ignored by "upgrade-safe"
> policy when the scriptPubKey doesn't match an even-more-specific pattern.
> Instead, I suggest we allow it (in the consensus layer only) in combination
> with scriptSig and with any scriptPubKey, and consider these cases to be
> "upgrade-safe" policy ignoring.
>
> The purpose of the second change is to be more flexible to any future
> softforks. I consider it minor because we don't know of any possibilities
> where it would actually be useful.
>
> Thoughts?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2017-04-26 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 20:28 Luke Dashjr
2017-04-26 8:51 ` praxeology_guy
2017-04-26 19:31 ` Johnson Lau [this message]
2017-04-26 20:01 ` Luke Dashjr
2017-04-26 20:09 ` Johnson Lau
2017-04-26 21:34 ` Russell O'Connor
2017-04-27 2:18 ` praxeology_guy
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=06E90C6D-8B4C-40A7-8807-8811A27AE401@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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