path: root/d6/9367e130d1133b795ea4f33aeab5b6734f370f

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F1A42B66
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Apr 2017 18:35:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5CEA61BB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Apr 2017 18:35:08 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1491330905910844.5661991020717;
	Tue, 4 Apr 2017 11:35:05 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 5 Apr 2017 02:35:01 +0800
References: <201704041803.57409.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201704041803.57409.luke@dashjr.org>
Message-Id: <B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 18:35:10 -0000

I feel particularly disappointed that while this BIP is 80% similar to =
my proposal made 2 months ago ( =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01349=
0.html ), Matt Corallo was only the person replied me. Also, this BIP =
seems ignored the txid malleability of the resolution tx, as my major =
technical critique of xblock design.

But anyway, here I=E2=80=99m only making comments on the design. As I =
said in my earlier post, I consider this more as an academic topic than =
something really ready for production use.

> This specification defines a method of increasing bitcoin transaction =
throughput without altering any existing consensus rules.

Softforks by definition tighten consensus rules

> There has been great debate regarding other ways of increasing =
transaction throughput, with no proposed consensus-layer solutions that =
have proven themselves to be particularly safe.

so the authors don=E2=80=99t consider segwit as a consensus-layer =
solution to increase transaction throughput, or not think segwit is =
safe? But logically speaking if segwit is not safe, this BIP could only =
be worse. OTOH, segwit also obviously increases tx throughput, although =
it may not be as much as some people wish to have.

> This specification refines many of Lau's ideas, and offers a much =
simpler method of tackling the value transfer issue, which, in Lau's =
proposal, was solved with consensus-layer UTXO selection.

The 2013 one is outdated. As the authors are not quoting it, not sure if =
they read my January proposal

>  extension block activation entails BIP141 activation.

I think extension block in the proposed form actually breaks BIP141. It =
may say it activates segregated witness as a general idea, but not a =
specific proposal like BIP141

> The merkle root is to be calculated as a merkle tree with all =
extension block txids and wtxids as the leaves.

It needs to be more specific here. How are they exactly arranged? I =
suggest it uses a root of all txids, and a root of all wtxids, and =
combine them as the commitment. The reason is to allow people to prune =
the witness data, yet still able to serve the pruned tx to light =
wallets. If it makes txid and wtxid as pairs, after witness pruning it =
still needs to store all the wtxids or it can=E2=80=99t reconstruct the =
tree

> Outputs signal to exit the extension block if the contained script is =
either a minimally encoded P2PKH or P2SH script.

This hits the biggest question I asked in my January post: do you want =
to allow direct exit payment to legacy addresses? As a block reorg will =
almost guarantee changing txid of the resolution tx, that will =
permanently invalidate all the child txs based on the resolution tx. =
This is a significant change to the current tx model. To fix this, you =
need to make exit outputs unspendable for up to 100 blocks. Doing this, =
however, will make legacy wallet users very confused as they do not =
anticipate funding being locked up for a long period of time. So you =
can=E2=80=99t let the money sent back to a legacy address directly, but =
sent to a new format address that only recognized by new wallet, which =
understands the lock up requirement. This way, however, introduces =
friction and some fungibility issues, and I=E2=80=99d expect people =
using cross chain atomic swap to exchange bitcoin and xbitcoin

To summarise, my questions are:
1. Is it acceptable to have massive txid malleability and transaction =
chain invalidation for every natural happening reorg?  Yes: the current =
spec is ok; No: next question (I=E2=80=99d say no)
2. Is locking up exit outputs the best way to deal with the problem? (I =
tried really hard to find a better solution but failed)
3. How long the lock-up period should be? Answer could be anywhere from =
1 to 100
4. With a lock-up period, should it allow direct exit to legacy address? =
(I think it=E2=80=99s ok if the lock-up is short, like 1-2 block. But is =
that safe enough?)
5. Due to the fungibility issues, it may need a new name for the tokens =
in the ext-block

> Verification of transactions within the extension block shall enforce =
all currently deployed softforks, along with an extra BIP141-like =
ruleset.

I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock. =
Especially, you don=E2=80=99t want to replicate the sighash bug to =
xblock. Also, requires scriptSig to be always empty

> This leaves room for 7 future soft-fork upgrades to relax DoS limits.

Why 7? There are 16 unused witness program versions

> Witness script hash v0 shall be worth the number of accurately counted =
sigops in the redeem script, multiplied by a factor of 8.

There is a flaw here: witness script with no sigop will be counted as 0 =
and have a lot free space

> every 73 bytes in the serialized witness vector is worth 1 additional =
point.

so 72 bytes is 1 point or 0 point? Maybe it should just scale everything =
up by 64 or 128, and make 1 witness byte =3D 1 point . So it won=E2=80=99t=
 provide any =E2=80=9Cfree space=E2=80=9D in the block.

> Currently defined witness programs (v0) are each worth 8 points. =
Unknown witness program outputs are worth 1 point. Any exiting output is =
always worth 8 points.

I=E2=80=99d suggest to have at least 16 points for each witness v0 =
output, so it will make it always more expensive to create than spend =
UTXO. It may even provide extra =E2=80=9Cdiscount=E2=80=9D if a tx has =
more input than output. The overall objective is to limit the UTXO =
growth. The ext block should be mainly for making transactions, not =
store of value (I=E2=80=99ll explain later)

> Dust Threshold

In general I think it=E2=80=99s ok, but I=E2=80=99d suggest a higher =
threshold like 5000 satoshi. It may also combine the threshold with the =
output witness version, so unknown version may have a lower or no =
threshold. Alternatively, it may start with a high threshold and leave a =
backdoor softfork to reduce it.

> Deactivation

It is a double-edged sword. While it is good for us to be able to =
discard an unused chain, it may create really bad user experience and =
people may even lose money. For example, people may have opened =
Lightning channels and they will find it not possible to close the =
channel. So you need to make sure people are not making time-locked tx =
for years, and require people to refresh their channel regularly. And =
have big red warning when the deactivation SF is locked in. Generally, =
xblock with deactivation should never be used as long-term storage of =
value.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94
some general comments:

1. This BIP in current form is not compatible with BIP141. Since most =
nodes are already upgraded to BIP141, this BIP must not be activated =
unless BIP141 failed to activate. However, if the community really =
endorse the idea of ext block, I see no reason why we couldn=E2=80=99t =
activate BIP141 first (which could be done in 2 weeks), then work =
together to make ext block possible. Ext block is more complicated than =
segwit. If it took dozens of developers a whole year to release segwit, =
I don=E2=80=99t see how ext block could become ready for production with =
less time and efforts.

2. Another reason to make this BIP compatible with BIP141 is we also =
need malleability fix in the main chain. As the xblock has a =
deactivation mechanism, it can=E2=80=99t be used for longterm value =
storage.

3. I think the size and cost limit of the xblock should be lower at the =
beginning, and increases as we find it works smoothly. It could be a =
predefined growth curve like BIP103, or a backdoor softfork. With the =
current design, it leaves a massive space for miners to fill up with =
non-tx garbage. Also, I=E2=80=99d also like to see a complete SPV =
fraud-proof solution before the size grows bigger.


> On 5 Apr 2017, at 02:03, Luke Dashjr via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Recently there has been some discussion of an apparent =
work-in-progress=20
> extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor =
Indutny,=20
> and Steven Pair. Since this hasn't been formally posted on the ML yet, =
perhaps=20
> it is still in pre-draft stages and not quite ready for review, but in =
light=20
> of public interest, I think it is appropriate to open it to =
discussion, and=20
> toward this end, I have reviewed the current revision.
>=20
> For reference, the WIP proposal itself is here:
>    https://github.com/tothemoon-org/extension-blocks
>=20
> =3D=3DOverall analysis & comparison=3D=3D
>=20
> This is a relatively complicated proposal, creating a lot of =
additional=20
> technical debt and complexity in comparison to both BIP 141 and =
hardforks. It=20
> offers no actual benefits beyond BIP 141 or hardforks, so seems =
irrational to=20
> consider at face value. In fact, it fits much better the inaccurate =
criticisms=20
> made by segwit detractors against BIP 141.
>=20
> That being said, this proposal is very interesting in construction and =
is for=20
> the most part technically sound. While ill-fit to merely making blocks =
larger,=20
> it may be an ideal fit for fundamentally different block designs such =
as=20
> Rootstock and MimbleWimble in absence of decentralised non-integrated=20=

> sidechains (extension blocks are fundamentally sidechains tied into =
Bitcoin=20
> directly).
>=20
> =3D=3DFundamental problem=3D=3D
>=20
> Extension blocks are a risk of creating two classes of "full nodes": =
those=20
> which verify the full block (and are therefore truly full nodes), and =
those=20
> which only verify the "base" block. However, because the extension is=20=

> consensus-critical, the latter are in fact not full nodes at all, and =
are left=20
> insecure like pseudo-SPV (not even real SPV) nodes. This technical =
nature is=20
> of course true of a softfork as well, but softforks are intentionally =
designed=20
> such that all nodes are capable of trivially upgrading, and there is =
no=20
> expectation for anyone to run with pre-softfork rules.
>=20
> In general, hardforks can provide the same benefits of an extension =
block, but=20
> without the false expectation and pointless complexity.
>=20
> =3D=3DOther problems & questions=3D=3D
>=20
>> These outpoints may not be spent inside the mempool (they must be =
redeemed=20
> from the next resolution txid in reality).
>=20
> This breaks the ability to spend unconfirmed funds in the same block =
(as is=20
> required for CPFP).
>=20
> The extension block's transaction count is not cryptographically =
committed-to=20
> anywhere. (This is an outstanding bug in Bitcoin today, but =
impractical to=20
> exploit in practice; however, exploiting it in an extension block may =
not be=20
> as impractical, and it should be fixed given the opportunity.)
>=20
>> The merkle root is to be calculated as a merkle tree with all =
extension=20
> block txids and wtxids as the leaves.
>=20
> This needs to elaborate how the merkle tree is constructed. Are all =
the txids=20
> followed by all the wtxids (tx hashes)? Are they alternated? Are txid =
and=20
> wtxid trees built independently and merged at the tip?
>=20
>> Output script code aside from witness programs, p2pkh or p2sh is =
considered=20
> invalid in extension blocks.
>=20
> Why? This prevents extblock users from sending to bare multisig or =
other=20
> various possible destinations. (While static address forms do not =
exist for=20
> other types, they can all be used by the payment protocol.)
>=20
> Additionally, this forbids datacarrier (OP_RETURN), and forces spam to =
create=20
> unprovably-unspendable UTXOs. Is that intentional?
>=20
>> The maximum extension size should be intentionally high.
>=20
> This has the same "attacks can do more damage than ordinary benefit" =
issue as=20
> BIP141, but even more extreme since it is planned to be used for =
future size=20
> increases.
>=20
>> Witness key hash v0 shall be worth 1 point, multiplied by a factor of =
8.
>=20
> What is a "point"? What does it mean multiplied by a factor of 8? Why =
not just=20
> say "8 points"?
>=20
>> Witness script hash v0 shall be worth the number of accurately =
counted=20
> sigops in the redeem script, multiplied by a factor of 8.
>=20
> Please define "accurately counted" here. Is this using BIP16 static =
counting,=20
> or accurately counting sigops during execution?
>=20
>> To reduce the chance of having redeem scripts which simply allow for =
garbage=20
> data in the witness vector, every 73 bytes in the serialized witness =
vector is=20
> worth 1 additional point.
>=20
> Is the size rounded up or down? If down, 72-byte scripts will carry 0=20=

> points...)
>=20
> =3D=3DTrivial & process=3D=3D
>=20
> BIPs must be in MediaWiki format, not Markdown. They should be =
submitted for=20
> discussion to the bitcoin-dev mailing list, not social media and news.
>=20
>> Layer: Consensus (soft-fork)
>=20
> Extension blocks are more of a hard-fork IMO.
>=20
>> License: Public Domain
>=20
> BIPs may not be "public domain" due to non-recognition in some =
jurisdictions.=20
> Can you agree on one or more of these?=20
> =
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended=
_licenses
>=20
>> ## Abstract
>>=20
>> This specification defines a method of increasing bitcoin transaction=20=

> throughput without altering any existing consensus rules.
>=20
> This is inaccurate. Even softforks alter consensus rules.
>=20
>> ## Motivation
>>=20
>> Bitcoin retargetting ensures that the time in between mined blocks =
will be=20
> roughly 10 minutes. It is not possible to change this rule. There has =
been=20
> great debate regarding other ways of increasing transaction =
throughput, with=20
> no proposed consensus-layer solutions that have proven themselves to =
be
> particularly safe.
>=20
> Block time seems entirely unrelated to this spec. Motivation is =
unclear.
>=20
>> Extension blocks leverage several features of BIP141, BIP143, and =
BIP144 for=20
> transaction opt-in, serialization, verification, and network services, =
and as=20
> such, extension block activation entails BIP141 activation.
>=20
> As stated in the next paragraph, the rules in BIP 141 are =
fundamentally=20
> incompatible with this one, so saying BIP 141 is activated is =
confusingly=20
> incorrect.
>=20
>> This specification should be considered an extension and modification =
to=20
> these BIPs. Extension blocks are _not_ compatible with BIP141 in its =
current=20
> form, and will require a few minor additional rules.
>=20
> Extension blocks should be compatible with BIP 141, there doesn=E2=80=99=
t appear to be=20
> any justification for not making them compatible.
>=20
>> This specification prescribes a way of fooling non-upgraded nodes =
into=20
> believing the existing UTXO set is still behaving as they would =
expect.
>=20
> The UTXO set behaves fundamentally different to old nodes with this =
proposal,=20
> albeit in a mostly compatible manner.
>=20
>> Note that canonical blocks containing entering outputs MUST contain =
an=20
> extension block commitment (all zeroes if nothing is present in the =
extension=20
> block).
>=20
> Please explain why in Rationale.
>=20
>> Coinbase outputs MUST NOT contain witness programs, as they cannot be=20=

> sweeped by the resolution transaction due to previously existing =
consensus=20
> rules.
>=20
> Seems like an annoying technical debt. I wonder if it can be avoided.
>=20
>> The genesis resolution transaction MAY also include a 1-100 byte =
pushdata in=20
> the first input script, allowing the miner of the genesis resolution =
to add a=20
> special message. The pushdata MUST be castable to a true boolean.
>=20
> Why? Unlike the coinbase, this seems to create additional technical =
debt with=20
> no apparent purpose. Better to just have a consensus rule every input =
must be=20
> null.
>=20
>> The resolution transaction's version MUST be set to the uint32 max =
(`2^32 -=20
> 1`).
>=20
> Transaction versions are signed, so I assume this is actually simply =
-1.=20
> (While signed transaction versions seemed silly to me, using it for =
special=20
> cases like this actually makes sense.)
>=20
>> ### Exiting the extension block
>=20
> Should specify that spending such an exit must use the resolution =
txid, not=20
> the extblock's txid.
>=20
>> On the policy layer, transaction fees may be calculated by =
transaction cost=20
> as well as additional size/legacy-sigops added to the canonical block =
due to=20
> entering or exiting outputs.
>=20
> BIPs should not specify policy at all. Perhaps prefix "For the =
avoidance of=20
> doubt:" to be clear that miners may perform any fee logic they like.
>=20
>> Transactions within the extended transaction vector MAY include a =
witness=20
> vector using BIP141 transaction serialization.
>=20
> Since extblock transactions are all required to be segwit, why =
wouldn't this=20
> be mandatory?
>=20
>> - BIP141's nested P2SH feature is no longer available, and no longer =
a=20
> consensus rule.
>=20
> Note this makes adoption slower: wallets cannot use the extblock until =
the=20
> economy has updated to support segwit-native addresses.
>=20
>> To reduce the chance of having redeem scripts which simply allow for =
garbage=20
> data in the witness vector, every 73 bytes in the serialized witness =
vector is=20
> worth 1 additional point.
>=20
> Please explain why 73 bytes in Rationale.
>=20
>> This leaves room for 7 future soft-fork upgrades to relax DoS limits.
>=20
> How so? Please explain.
>=20
>> A consensus dust threshold is now enforced within the extension =
block.
>=20
> Why?
>=20
>> If the second highest transaction version bit (30th bit) is set to to =
`1`=20
> within an extension block transaction, an extra 700-bytes is reserved =
on the=20
> transaction space used up in the block.
>=20
> Why wouldn't users set this on all transactions?
>=20
>> `default_witness_commitment` has been renamed to=20
> `default_extension_commitment` and includes the extension block =
commitment=20
> script.
>=20
> `default_witness_commitment` was never part of the GBT spec. At least =
describe=20
> what this new key is.
>=20
>> - Deployment name: `extblk` (appears as `!extblk` in GBT).
>=20
> Should be just `extblk` if backward compatibility is supported (and =
`!extblk`=20
> when not).
>=20
>> The "deactivation" deployment's start time...
>=20
> What about timeout? None? To continue the extension block, must it be=20=

> deactivated and reactivated in parallel?
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev