[bitcoin-dev] Segwit v2

[bitcoin-dev] Segwit v2

[Luke Dashjr]

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

Re: [bitcoin-dev] Segwit v2

[praxeology_guy]

[-- Attachment #1: Type: text/plain, Size: 4513 bytes --]

Luke,

I can't really advise on your proposed changes... but I have a couple new suggestions:

=== Future Proof Commitment Extension Methodology ===
1. I'm not a fan of how ambiguous the direction is on handling future commitment extensions. See https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Extensible_commitment_structure.

1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
39th byte onwards: Optional data with no consensus meaning
* "witness reserved value" _must_ also go in the input's scriptSig/witness field... blah blah blah warning warning.

Where is the new "witness reserved value" going to go for the next extension? Why waste 32 bytes in some arbitrary location, and then later when there is an extension, eventually be wasting 32 more bytes at some other arbitrary location?

Here's a more well defined/future proof proposal that uses fewer bytes:

1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(extension root A|extension root B|extension root C...)

variable bytes - Extension identifiers: array of extension identifiers
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
next byte onwards - Optional data with no consensus meaning

- The extension identifiers are ordered the same as the order of the extension roots in the merkle root.
- The extension identifiers can be highly compacted together using a custom compression algorithm.
- The array length for the extension roots can be a utf8-like format, where up to 0-127 can be represented with one byte, and 128-16383 can be represented with two bytes.
- The extension roots themselves only need to be provided for the sake of clients that are unable or not desiring to compute a particular extension root, but do want to verify some of the extension roots.

This design is much more future proof, and uses less space. With SegWit only, this would take up maybe 1 byte for the extension identifiers (compressed length 1 and id 0 for wtxroot), and 1 byte for the extension roots (array length = 0).

=== Replay Attack Prevention ===
2. Implement the Policy ID 'replay attack" prevention that I have suggested (but is in dev list purgatory), which increases each wtx length by 1 byte. This can be reduced in a block by clustering Policy ID ranges in the coinbase... or by guessing the Policy ID. Witness data would sign on the Policy ID... preventing replay if at least one branch adopted a new Policy ID.

Cheers,
Praxeology Guy

-------- Original Message --------
Subject: [bitcoin-dev] Segwit v2
Local Time: April 20, 2017 3:28 PM
UTC Time: April 20, 2017 8:28 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: bitcoin-dev@lists.linuxfoundation.org

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

[-- Attachment #2: Type: text/html, Size: 5991 bytes --]

Re: [bitcoin-dev] Segwit v2

[Johnson Lau]

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

Re: [bitcoin-dev] Segwit v2

[Luke Dashjr]

On Wednesday 26 April 2017 7:31:38 PM Johnson Lau wrote:
> 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.

Fair enough, I guess. Although I think the dummy marker could actually be non-
consensus critical so long as the hashing replaces it with a 0.

> 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.

There are things scriptSig can do that witness cannot today - specifically add 
additional conditions under the signature. We can always obsolete scriptSig 
later, after segwit has provided an alternative way to do this.

> Maybe we could restrict witness to IsPushOnly() scriptPubKey, so miners
> can’t put garbage to legacy txs.

They already can malleate transactions and add garbage to the blocks. I don't 
see the benefit here.

Luke

Re: [bitcoin-dev] Segwit v2

[Johnson Lau]

> On 27 Apr 2017, at 04:01, Luke Dashjr <luke@dashjr.org> wrote:
> 
> On Wednesday 26 April 2017 7:31:38 PM Johnson Lau wrote:
>> 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.
> 
> Fair enough, I guess. Although I think the dummy marker could actually be non-
> consensus critical so long as the hashing replaces it with a 0.
> 
>> 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.
> 
> There are things scriptSig can do that witness cannot today - specifically add 
> additional conditions under the signature. We can always obsolete scriptSig 
> later, after segwit has provided an alternative way to do this.

You can do this with witness too, which is also cheaper. Just need to make sure the signature covers a special part of the witness. I will make a proposal to Litecoin soon, which allows signing and executing extra scripts in witness. Useful for things like OP_PUSHBLOCKHASH

> 
>> Maybe we could restrict witness to IsPushOnly() scriptPubKey, so miners
>> can’t put garbage to legacy txs.
> 
> They already can malleate transactions and add garbage to the blocks. I don't 
> see the benefit here.

Witness is cheaper and bigger

> 
> Luke

Re: [bitcoin-dev] Segwit v2

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, Apr 26, 2017 at 4:01 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are things scriptSig can do that witness cannot today - specifically
> add
> additional conditions under the signature. We can always obsolete scriptSig
> later, after segwit has provided an alternative way to do this.
>

I'm not sure what you are referring to here.  The data in the scriptSigs
are never signed.  The scriptSigs are always stripped from the transaction
before the sigHash is made.

[-- Attachment #2: Type: text/html, Size: 932 bytes --]

Re: [bitcoin-dev] Segwit v2

[praxeology_guy]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

Johnson Lau,

> not change the commitment structure as suggested by another post

Not sure if you realize my proposal is backwards compatible. We could also merge the two arrays, which would be harder to compress, but a more simple format. Below I gave an example of how this would be backwards compatible.

1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
bytes onwards: Optional data with no consensus meaning

* "witness reserved value" _must_ also go in the input's scriptSig/witness field

Here is an example of the "Extension roots" with this format:
Extension roots: 2, {0, 0, []}, {1, 0, []}

size = 2 // two elements in Commitment hash
{ext.id = 0, length = 0, empty} // First element is the wtxid merkle root hash, must be calculated, not specified here
{ext.id = 1, length = 0, empty} // Second element is the "witness reserved value", which is found in the scriptSig

Later after all the miners upgrade, we could stop using the ext.id = 1 and also stop putting the unneccesary value in scriptSig.

[-- Attachment #2: Type: text/html, Size: 1605 bytes --]