Re: [bitcoin-dev] Segwit v2
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.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segwit v2
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segwit v2
> On 27 Apr 2017, at 04:01, Luke Dashjr 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segwit v2
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segwit v2
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 > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Draft BIP: Segwit deployment with versionbits and guaranteed lock-in
See Segwit v2 thread. Maybe we can collaborate on combining these. On Wednesday 26 April 2017 6:15:26 PM shaolinfry via bitcoin-dev wrote: > This is a draft BIP proposal to redeploy segwit using BIP-8, from the day > after the current BIP9 segwit times out. > > This BIP could be deployed long before Nov 15th 2016, for example in July > allowing wide deployment to begin soon. The timeout (and this > useractivation) could be set to roughly a year from then. However, > considering around 70% of nodes upgraded to witness capability within 5-6 > months, I personally think we could reduce the time, especially > considering how much people want segwit - but I understand the need for > more caution in Bitcoin. > > Preliminary dates are deploy within a couple months, startdate Nov 16th > 2017, BIP8 timeout July 4th 2018. > > > BIP: ? > Layer: Consensus (soft fork) > Title: Segwit deployment with versionbits and guaranteed lock-in > Author: Shaolin Fry > Comments-Summary: No comments yet. > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP- > Status: Draft > Type: Standards Track > Created: 2017-04-14 > License: BSD-3-Clause > CC0-1.0 > > > ==Abstract== > > This document specifies a user activated soft fork for BIP141, BIP143 and > BIP147 using versionbits with guaranteed lock-in. > > ==Motivation== > > Miners have been reluctant to signal the BIP9 segwit deployment despite a > large portion of the Bitcoin ecosystem who want the soft fork activated. > This BIP specifies a user activated soft fork (UASF) that deploys segwit > again using versionbits with guaranteed lock-in on timeout if the BIP is > not already locked-in or activated by the timeout. This ensures users have > sufficient time to prepare and no longer require a miner supermajority, > while still allowing for an earlier miner activated soft fork (MASF). > > ==Reference implementation== > > https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-fla > gday > > ==Specification== > > This deployment will set service bit (1<<5) as NODE_UAWITNESS. > > ==Deployment== > > This BIP will be deployed by BIP8 with the name "uasegwit" and using bit 2. > > For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 > UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC > (Epoch timestamp 1530662400). > > For Bitcoin testnet, segwit is already activated so no deployment is > specified. > > ==Rationale== > > This BIP can be deployed well in advance of the BIP8 '''starttime''' so > that the '''timeout''' will be sufficiently far in the future to allow > Bitcoin users to uprgade in preparation. > > The '''starttime''' of this BIP is after the BIP9 "segwit" timeout to > remove compatibility issues with old nodes. > > ==References== > > https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki > > https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki > > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki > > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki > > https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki > > ==Copyright== > > This document is dual licensed as BSD 3-clause, and Creative Commons CC0 > 1.0 Universal. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Draft BIP: Segwit deployment with versionbits and guaranteed lock-in
This is a draft BIP proposal to redeploy segwit using BIP-8, from the day after the current BIP9 segwit times out. This BIP could be deployed long before Nov 15th 2016, for example in July allowing wide deployment to begin soon. The timeout (and this useractivation) could be set to roughly a year from then. However, considering around 70% of nodes upgraded to witness capability within 5-6 months, I personally think we could reduce the time, especially considering how much people want segwit - but I understand the need for more caution in Bitcoin. Preliminary dates are deploy within a couple months, startdate Nov 16th 2017, BIP8 timeout July 4th 2018. BIP: ? Layer: Consensus (soft fork) Title: Segwit deployment with versionbits and guaranteed lock-in Author: Shaolin Fry Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP- Status: Draft Type: Standards Track Created: 2017-04-14 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a user activated soft fork for BIP141, BIP143 and BIP147 using versionbits with guaranteed lock-in. ==Motivation== Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF). ==Reference implementation== https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday ==Specification== This deployment will set service bit (1<<5) as NODE_UAWITNESS. ==Deployment== This BIP will be deployed by BIP8 with the name "uasegwit" and using bit 2. For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400). For Bitcoin testnet, segwit is already activated so no deployment is specified. ==Rationale== This BIP can be deployed well in advance of the BIP8 '''starttime''' so that the '''timeout''' will be sufficiently far in the future to allow Bitcoin users to uprgade in preparation. The '''starttime''' of this BIP is after the BIP9 "segwit" timeout to remove compatibility issues with old nodes. ==References== https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki ==Copyright== This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segwit v2
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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
