path: root/9f/0589cb3f8e09246ac814579ea2e025d6e4737d

Return-Path: <laolu32@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 23899902
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 14:05:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
	[209.85.161.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB276FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 14:05:49 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id i203so6428483ywc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Apr 2017 07:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=YcxSVmrroiGiVy1El63Oxw3NgKaYVIfUNiAhz0fJKRo=;
	b=bTmlftHhrNbiy9wCmfWeUDKcx2R/tz1L0wLCBSY3XBntTsHfVaq3vV4F0CoHBkUgnl
	d9FrZ5E7BfgCp86v8mhnrvg0m4k/+Y+3GnpYnfSyDvdZakfRpeJeobiZ3+jyd8mPO670
	aMZZqFRGc/YKi0DqAgJcC8fsIt3PKrtudjGAz9+LwnfChyAZLTTQ7+FNmSr7mVibaORk
	XKflJveoMFwd99bb+6i6xWrs1WmWss4YRK+p583iTaGt+v8YKRgFFLRP21lbcKjghGar
	JR7t47Nby3E4ufSQhc2EHu1HggYnkXsDTQ/XRaGXa6rt4j5X7scEYpX/cGAbHDR/6lur
	1C1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=YcxSVmrroiGiVy1El63Oxw3NgKaYVIfUNiAhz0fJKRo=;
	b=RK917m+AreusvyRJXj410J1rkmGBKCsgWtqp3kagczvrnRlgqe7ZiSVGsmTYEAjrLi
	zq7Ot5SoHQ6JtxgR9cTFzTCoXRF8B+Osx+lcHNS0FQpui4JtoEp/GQSjsxpQRVI9EH/P
	XyjT+chswdRtpo2qwgcWu3g/l/lSIZdPRHf5k19oeXByf+rrEI1QBmZod2JqRqjnXmOS
	JeQbUfFgGx7u0CWNrStt93b/3Zx8wHF0JGwm0epeNCb4tx+6xiA3mF0botg60jzgq3rO
	WEgG45mwiw7P3UC2ogL74P3AMs4TlbHk+9fnknBk6+VQ3Fu4VVheklz++HfxkoBJ1js9
	mnKA==
X-Gm-Message-State: AFeK/H244UroRPYuJd2WbbUQQ6FHvIGVi+U0N7rdxkXDo5nXiUBOc1sP4MiJiuuYzh/wouoaKFTnZ0h3eQrZrA==
X-Received: by 10.129.160.83 with SMTP id x80mr18269106ywg.342.1491401148335; 
	Wed, 05 Apr 2017 07:05:48 -0700 (PDT)
MIME-Version: 1.0
References: <201704041803.57409.luke@dashjr.org>
	<B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
In-Reply-To: <B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 05 Apr 2017 14:05:37 +0000
Message-ID: <CAO3Pvs9DF6F4gDgrNPoUw5bqwb6ajDwwVP9NpcLzpZMzzgMQjw@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=94eb2c07de54aa0b49054c6be310
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 05 Apr 2017 14:06:26 +0000
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: Wed, 05 Apr 2017 14:05:54 -0000

--94eb2c07de54aa0b49054c6be310
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Y'all,

Thanks to luke-jr and jl2012 for publishing your analysis of the
xblocks proposal. I'd like to also present some analysis but instead focus
on the professed LN safety enhancing scheme in the proposal. It's a bit
underspecified, so I've taken the liberty of extrapolating a bit to fill
in the gaps to the point that I can analyze it.

TLDR; The xblock proposal includes a sub-proposal for LN which is
essentially a block-size decrease for each open channel within the network.
This decrease reserves space in blocks to allow honest parties guaranteed
space in the blocks to punish dishonest channel counter parties. As a resul=
t
the block size is permanently decreased for each channel open. Some may
consider this cost prohibitively high.

>> If the second highest transaction version bit (30th bit) is set to to `1=
`
>> within an extension block transaction, an extra 700-bytes is reserved on
>> the transaction space used up in the block.

> Why wouldn't users set this on all transactions?

As the proposal stands now, it seems that users _are_ able to unilaterally
use this for all their Bitcoin transactions, as there's no additional cost
to using the smart-contract safety feature outlined in the proposal.

The new safety measures proposed near the end of this xblock proposal
could itself consume a dedicated document outlining the prior background,
context, and implications of this new safety feature. Throughout the rest
of this post, I'll be referring to the scheme as a Pre-Allocated
Smart-contract Dispute arena (PASDA, chosen because it sounds kinda like
"pasta", which brings me many keks). It's rather insufficiently described
and
under specified as it stands in the proposal. As a result, if one doesn't
have the necessary prior context, it might've been skipped over entirely
as it's difficult to extract the sub-proposal from the greater proposal. I
think I possess the necessary prior context required to required to
properly analyze the sub-proposal. As a result, I would like to illuminate
the readers of the ML so y'all may also be able to evaluate this
sub-proposal independently.


## Background

First, some necessary background. Within LN as it exists today there is
one particularly nasty systematic risk related to blockchain availability
in the case of a channel dispute. This risk is clearly outlined in the
original white paper, and in my opinion a satisfactory solution to the
risks which safe guard the use of very high-value channels has yet to be
presented.


### Chain Spam/Censorship Attack Vector

The attack vector mentioned in the original paper is a reoccurring attack
in systems of this nature: DoS attacks. As it stands today, if a channel
counterparty is able to (solely, or in collaboration with other attackers)
prevent one from committing a transaction to the chain, they're able to
steal money from the honest participant in the channel. The attack
proceeds something like this:

   * Mallory opens a very large channel with me.
   * We transfer money back and forth in the channel as normal. The nature
     of these transfers isn't very important. The commitment balances may
     be modified due to Mallory making multi-hop payments through my
     channel, or possibly from Mallory directly purchasing some goods I
     offer, paying via the channel.
   * Let's call the current commitment number state S_i. In the lifetime
     of the channel there may exist some state S_j (i < j) s.t Mallory's
     balance in S_i, is larger than S_j.
   * At this point, depending on the value of the channel's time-based
     security parameter (T) it may be possible for Mallory to broadcast
     state S_i (which has been revoked), and prevent me being able to
     include by my punishment transaction (PTX) within the blockchain.
   * If Mallory is able to incapacitate me for a period of time T, or
     censor my transactions from the chain (either selectively or via a
     spam attack), then at time K (K > T + B, where B is the time the
     commitment transaction was stamped in the chain), then she'll be free
     to walk away with her settled balance at state S_i. For the sake of
     simplicity, we're ignoring HTLC's.
   * Mallory's gain is the difference between the balance at state S_i and
     S_j. Deepening on the gap between the states, my settled balance at
     state S_i and the her balance delta, she may be able to fully recoup
     the funds she initially place in the channel.


### The Role of Channel Reserves as Partial Mitigation

A minor mitigation to this attack that's purely commitment transaction
policy is to mandate that Mallory's balance in the channel never dips
below some reserve value R. Otherwise, if at state S_j, Mallory has a
settled balance of 0 within he channel (all the money if on my side), then
the attack outline above can under certain conditions be _costless_ from
her PoV. Replicate this simultaneously across the network in a synchronized
manner (possibly getting some help from your miner friends) and this
becomes a bit of a problem (to say the least).

Taking this a step further another mitigation that's been proposed is to
also use the channel reserve to implement a _ceiling_ on the maximum size
of _any_ in flight HTLC. Similar to the scheme above, this is meant to
eliminate the possibility of a "costless" attack, as if channel throughput
is artificially constrained, then the value of pending HTLC's isn't
enticing enough to launch a channel breach attack.


### Analysis of Attack Feasibility/Difficulty

The difficulty of the attack is dependant on the time-denominated security
parameter T, and the adversaries ability to collude with miners. Purely
spamming the chain given a very larger T value may be prohibitively
expensive for the attacker and their profit from launching the attack
would need to outweigh the cost in transaction fees and idle bitcoin
required to launch the attack. Considering the case of colluding with
miners, if mining is highly centralized (as it is now), then that may be a
more attractive attack avenue. In a world of highly decentralized mining
(let's say a lofty goal of no pool commanding > 5% of the hash power),
then the attack is much more difficult.

(as an aside schemes that involve transactions committing to the inputs
they're spending and revealing them at a later date/block (committed
transactions) may address the miner censorship attack vector)

Depending one's target use of channels, the individuals they open channels
with, the applications that run on top of the channels, the amount of
coins within the channel, and the choice of the time parameter T, the
attack outline above may or may not be an issue from your PoV.  However,
in order to realize LN's maximum potential of being able to enter a
smart-contract with a complete stranger on the internet trustlessly,
without fearing conditions that may lead to monetary losses, the attack
vector should be mitigated if possible.

In the words of The Architect of the Matrix (and referenced by Tadge at
his "Level of LN" talk at Scaling Bitcoin Hong Kong: "There are levels of
survival we are prepared to accept". There exist levels of LN and usage of
channels, that may not consider this a dire issue.

OK, with the necessary background and context laid out, I'll now analyze
the solution proposed within the greater xblock proposal, making a brief
detour to briefly described another proposed solution.

### Timestop

A prior proposed solution to the failure scenario described above is
what's known as "time stop". This was proposed by gmaxwell and was briefly
touched upon in the original LN white paper. The mechanism of the
time-denominated security parameter T in today's channel construction is
enforced using OpCheckSequenceVerify. After broadcasting a commitment
transaction, all outputs paying to the broadcaster of the commitment are
encumbered with a relative time delay of T blocks, meaning they are unable
to claim the funds until time T has elapsed. This time margin gives the
honest party an opportunity to broadcast their punishment transaction
iff, the broadcaster has broadcast a prior revoked state.

The idea of time stomp is to introduce a special sequence-locks block
height to the system. This block height would increase with each block
along with the regular block height _unless_ the block reaches a certain
sustained "high water mark". As an example, let's assume that when 3
blocks in row are above 75% capacity, then the sequence-lock clock stops
ticking.

The effect of this change is to morph the security risk into simply a
postponement of the judgment within the contract. With this, DoS attacks
simply delay the (seemingly) inevitable punishment of the dishonest party
within the contract.

Aside from some informal discussions and the brief section within the
original white paper, many details of this proposal are left
underspecified. For example: how do miners signal to full nodes that the
sequence-lock clock has stopped? What's the high water mark threshold? Can
it go on indefinitely? Should this feature be opt-in?

I think this proposal should be considered in tandem with the proposal
within the xblock proposal as both have a few unanswered questions that
need to be further explored.

## Pre-Allocated Smart-Contract Dispute Area (PASDA)

Aight, now to the LN enhancing proposal that's buried within the
greater xblock proposal. Introducing some new terminology, I've been
calling this a: Pre-Allocated Smart-contract Dispute Arena or (PASDA) for
short. In a nut shell, the key idea of the proposal is this: transactions
that mark the commencement of a smart contract who's security depends on
availability of block space for disputes are able to _pre allocate_ a
section of the block that will _always_ be _reserved_ for dispute
transactions. With this, contracts is  _guaranteed_ space in blocks to
handle disputes in the case that the contract breaks down. As an analogy:
when you enter in a contract with a contractor to build your dream
kitchen, you _also_ go to a court and reserve a 1-hour block in their
scheduled to handle a dispute _just in case_ one arises. In the event of a
peaceful resolution to the contract, the space is freed up.

The description in the paper is a bit light on the details, so I'll say up
front that I'm extrapolating w.r.t to some mechanisms of the construction.
However, I've been involved in some private conversations where the idea
was thrown around, so I think I have enough context to _maybe_ fill in
some of the gaps in the proposal.

I'll now restate the proposal. Smart contract transactions set a certain
bit in their version number. This bit indicates that they wish to
pre-allocate N bytes in _all_ further blocks _until_ the contract has been
reserved. In the specific context of payment channels, this means that
once a channel is open, until it has been closed, it _decreases_ the
available block size for all other transactions. As this is a very
aggressive proposal I think the authors took advantage of the new design
space within xblocks to include something that may not be readily accepted
as a modification to the rules of the main chain.

The concrete parameters chosen in the proposal are: each channel opening
transaction reserves 700-bytes within _each_ block in the chain until the
transaction has been closed. This pre-allocation has the following
constraint: a transaction can _only_ take advantage of this allocation iff
it's spending the _first_ output of a smart-contract transaction (has a
particular bit in the version set). This means that only dispute
resolution transactions can utilize this space.

The proposal references two allocations, which I've squinted very hard at
for half a day in an attempt to parse the rules governing them, but so far
I've been unable to glean any further details. From my squinting, I
interpret that half of the allocation is reserved for spending the
self-output of a transaction in the last 2016 blocks (two weeks) and the
other half is dedicated to spending the first output of a commitment
transaction in the _same_ block.

I'm unsure as to why these allocations are separate, and why they aren't
just combined into a single allocation.

### Modification to LN Today

This change would require a slight modification to LN as it's currently
defined today. ATM, we use BIP 69 in order the inputs and outputs of a
transaction. This is helpful as it lets us just send of signatures for new
states as both sides already know the order of the inputs and outputs.
With PASDA, we'd now need to omit the to-self-output (the output in my
commitment transaction paying to myself my settled balance) from this
ordering and _always_ make it the first output (txid:0).

The second change is that this proposal puts a ceiling on on the CSV value
allowed by any channel. All CSV delays _must-weeks otherwise, they're
unable to take advantage of the arena.

### Modifications to Bitcoin

In order to implement this within Bitcoin, a third utxo set (regular
block, xblock) must be maintained by all full nodes. Alternatively, this
can just be a bit in the xblock utxo set. The implementation doesn't
really matter. Before attempting to pack transactions into a block, the
total allocation within the PASDA utxo-set must be summed up, and
subtracted from the block size cap. Only transactions which validly spend
from one of these UTXO's are able to take advantage of the new space in
the block.

## Analysis of PASDA

OK, now for some analysis. First, let's assume that transactions which
create PASDA UTXO's aren't subject to any additional constraints. If so,
then this means that _any_ transaction can freely create PASDA UTXO's and
_decrease_ the block size for _all_ transactions until the UTXO has been
spent. If my interpretation is correct, then this introduces a new attack
vector which allows _anyone_ to nearly permanently decrease the block size
for all-time with next to zero additional cost. If this is correct, then
it seems that miners have _zero_ incentive to _ever_ include a transaction
that creates a PASDA output in their blocks as it robs them of future
revenue and decreases the available capacity in the system, possibly
permanently proportionally to _each_ unspent PASDA output in the chain.

Alternatively, let's say the transactions which create PASDA outputs
_must_ pay a disproportionately high fee in order to pay up front for
their consumption of the size within all future blocks. If so, then a
question that arises is: How large a fee? If the fee is very large, then
the utilization of the smart-contract battling arena is only reserved to
very high valued channels who can afford very high fees. This may be
acceptable as if you have a $5 channel, then are you really at risk at
such a large scale attack on Bitcoin just to steal $5 from you? It's
important to note that many attacks on LN's contract resolution
capabilities are also a direct attack on Bitcoin. However, in a world of
dynamic fees, then it may be the case that the fee paid 6 months ago is
now a measly fee an no longer covers the costs to miners (and even the
entire system...).

Finally, here's something I thought of earlier today that possibly
mitigates the downside from the PoV of the miners (everyone else must
still accept the costs of a permanent block size decrease). Let's say that
in order to create a PASDA output fees are paid as normal. However, for
_each_ subsequent block, the participants of the contract _must_ pay a
tribute to miners to account for their loss in revenue due to the
reduction in block size. Essentially, all PASDA outputs must pay _rent_
for their pre-allocated space. If rent isn't paid sufficiently and on-time,
then the pre-allocate arena space is revoked by miners. There're a few
ways to construct this payment, but I'll leave that to follow up work as I
just want to shed some light on the PASDA and its implications.

## Conclusion

I've attempted to fill in some gaps for y'all w.r.t exactly what the
sub-proposal within the greater xblock proposal consists of and some
possible implications. I'd like to note that I've taken the liberty of
filling on some gaps within the sub-proposal as only a single section
within the greater proposal has been allocated to it. PASDA itself could
likely fill up an entirely distinct propsal by itself spanning several
pages. To the authors of the proposal: if my interpretation is inaccurate
please correct me as I'd also like to better understand the proposal. It's
possible that everything I've said in this (now rather long) email is
incorrect.

If you've made it this far, thank you for taking the time out of your day
to consider my thoughts. It's my hope that we can further analyze this
sub-proposal in detail and discuss its construction as well as its
implications on smart-contracts like payment channels on top of Bitcoin.

PASDA purports to address one half of the systematic risks in LN by
possibly eliminating the DoS vector attack against LN. However, the costs
of PASDA are very high, and possibly prohibitively so. In my opinion, the
second attack vector lies in the ability of miners to arbitrarily censor
transactions spending a particular output. Fungibility enhancing
techniques such as Committed Transactions may be a viable path forward to
patch this attack vector.

-- roasbeef


On Tue, Apr 4, 2017 at 8:35 PM Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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/0134=
90.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 sai=
d 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 solutio=
n to
> increase transaction throughput, or not think segwit is safe? But logical=
ly
> speaking if segwit is not safe, this BIP could only be worse. OTOH, segwi=
t
> 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 combin=
e
> them as the commitment. The reason is to allow people to prune the witnes=
s
> 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 al=
l
> 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 almo=
st
> 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 m=
oney 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 xbitc=
oin
>
> 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 i=
n
> 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=99=
t provide
> any =E2=80=9Cfree space=E2=80=9D in the block.
>
> > Currently defined witness programs (v0) are each worth 8 points. Unknow=
n
> 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 outp=
ut. 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 thre=
shold like 5000
> satoshi. It may also combine the threshold with the output witness versio=
n,
> so unknown version may have a lower or no threshold. Alternatively, it ma=
y
> 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 a=
nd
> 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 t=
o
> 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 unle=
ss
> 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 BIP14=
1 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 bl=
ock 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 so=
lution
> before the size grows bigger.
>
>
> > On 5 Apr 2017, at 02:03, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Recently there has been some discussion of an apparent work-in-progress
> > extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor
> Indutny,
> > and Steven Pair. Since this hasn't been formally posted on the ML yet,
> perhaps
> > it is still in pre-draft stages and not quite ready for review, but in
> light
> > of public interest, I think it is appropriate to open it to discussion,
> and
> > toward this end, I have reviewed the current revision.
> >
> > For reference, the WIP proposal itself is here:
> >    https://github.com/tothemoon-org/extension-blocks
> >
> > =3D=3DOverall analysis & comparison=3D=3D
> >
> > This is a relatively complicated proposal, creating a lot of additional
> > technical debt and complexity in comparison to both BIP 141 and
> hardforks. It
> > offers no actual benefits beyond BIP 141 or hardforks, so seems
> irrational to
> > consider at face value. In fact, it fits much better the inaccurate
> criticisms
> > made by segwit detractors against BIP 141.
> >
> > That being said, this proposal is very interesting in construction and
> is for
> > the most part technically sound. While ill-fit to merely making blocks
> larger,
> > it may be an ideal fit for fundamentally different block designs such a=
s
> > Rootstock and MimbleWimble in absence of decentralised non-integrated
> > sidechains (extension blocks are fundamentally sidechains tied into
> Bitcoin
> > directly).
> >
> > =3D=3DFundamental problem=3D=3D
> >
> > Extension blocks are a risk of creating two classes of "full nodes":
> those
> > which verify the full block (and are therefore truly full nodes), and
> those
> > which only verify the "base" block. However, because the extension is
> > consensus-critical, the latter are in fact not full nodes at all, and
> are left
> > insecure like pseudo-SPV (not even real SPV) nodes. This technical
> nature is
> > of course true of a softfork as well, but softforks are intentionally
> designed
> > such that all nodes are capable of trivially upgrading, and there is no
> > expectation for anyone to run with pre-softfork rules.
> >
> > In general, hardforks can provide the same benefits of an extension
> block, but
> > without the false expectation and pointless complexity.
> >
> > =3D=3DOther problems & questions=3D=3D
> >
> >> These outpoints may not be spent inside the mempool (they must be
> redeemed
> > from the next resolution txid in reality).
> >
> > This breaks the ability to spend unconfirmed funds in the same block (a=
s
> is
> > required for CPFP).
> >
> > The extension block's transaction count is not cryptographically
> committed-to
> > anywhere. (This is an outstanding bug in Bitcoin today, but impractical
> to
> > exploit in practice; however, exploiting it in an extension block may
> not be
> > as impractical, and it should be fixed given the opportunity.)
> >
> >> The merkle root is to be calculated as a merkle tree with all extensio=
n
> > block txids and wtxids as the leaves.
> >
> > This needs to elaborate how the merkle tree is constructed. Are all the
> txids
> > followed by all the wtxids (tx hashes)? Are they alternated? Are txid a=
nd
> > wtxid trees built independently and merged at the tip?
> >
> >> Output script code aside from witness programs, p2pkh or p2sh is
> considered
> > invalid in extension blocks.
> >
> > Why? This prevents extblock users from sending to bare multisig or othe=
r
> > various possible destinations. (While static address forms do not exist
> for
> > other types, they can all be used by the payment protocol.)
> >
> > Additionally, this forbids datacarrier (OP_RETURN), and forces spam to
> create
> > unprovably-unspendable UTXOs. Is that intentional?
> >
> >> The maximum extension size should be intentionally high.
> >
> > This has the same "attacks can do more damage than ordinary benefit"
> issue as
> > BIP141, but even more extreme since it is planned to be used for future
> size
> > increases.
> >
> >> Witness key hash v0 shall be worth 1 point, multiplied by a factor of =
8.
> >
> > What is a "point"? What does it mean multiplied by a factor of 8? Why
> not just
> > say "8 points"?
> >
> >> Witness script hash v0 shall be worth the number of accurately counted
> > sigops in the redeem script, multiplied by a factor of 8.
> >
> > Please define "accurately counted" here. Is this using BIP16 static
> counting,
> > or accurately counting sigops during execution?
> >
> >> To reduce the chance of having redeem scripts which simply allow for
> garbage
> > data in the witness vector, every 73 bytes in the serialized witness
> vector is
> > worth 1 additional point.
> >
> > Is the size rounded up or down? If down, 72-byte scripts will carry 0
> > points...)
> >
> > =3D=3DTrivial & process=3D=3D
> >
> > BIPs must be in MediaWiki format, not Markdown. They should be submitte=
d
> for
> > discussion to the bitcoin-dev mailing list, not social media and news.
> >
> >> Layer: Consensus (soft-fork)
> >
> > Extension blocks are more of a hard-fork IMO.
> >
> >> License: Public Domain
> >
> > BIPs may not be "public domain" due to non-recognition in some
> jurisdictions.
> > Can you agree on one or more of these?
> >
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommende=
d_licenses
> >
> >> ## Abstract
> >>
> >> This specification defines a method of increasing bitcoin transaction
> > throughput without altering any existing consensus rules.
> >
> > This is inaccurate. Even softforks alter consensus rules.
> >
> >> ## Motivation
> >>
> >> Bitcoin retargetting ensures that the time in between mined blocks wil=
l
> be
> > roughly 10 minutes. It is not possible to change this rule. 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.
> >
> > Block time seems entirely unrelated to this spec. Motivation is unclear=
.
> >
> >> Extension blocks leverage several features of BIP141, BIP143, and
> BIP144 for
> > transaction opt-in, serialization, verification, and network services,
> and as
> > such, extension block activation entails BIP141 activation.
> >
> > As stated in the next paragraph, the rules in BIP 141 are fundamentally
> > incompatible with this one, so saying BIP 141 is activated is confusing=
ly
> > incorrect.
> >
> >> This specification should be considered an extension and modification =
to
> > these BIPs. Extension blocks are _not_ compatible with BIP141 in its
> current
> > form, and will require a few minor additional rules.
> >
> > Extension blocks should be compatible with BIP 141, there doesn=E2=80=
=99t appear
> to be
> > any justification for not making them compatible.
> >
> >> This specification prescribes a way of fooling non-upgraded nodes into
> > believing the existing UTXO set is still behaving as they would expect.
> >
> > The UTXO set behaves fundamentally different to old nodes with this
> proposal,
> > albeit in a mostly compatible manner.
> >
> >> Note that canonical blocks containing entering outputs MUST contain an
> > extension block commitment (all zeroes if nothing is present in the
> extension
> > block).
> >
> > Please explain why in Rationale.
> >
> >> Coinbase outputs MUST NOT contain witness programs, as they cannot be
> > sweeped by the resolution transaction due to previously existing
> consensus
> > rules.
> >
> > Seems like an annoying technical debt. I wonder if it can be avoided.
> >
> >> The genesis resolution transaction MAY also include a 1-100 byte
> pushdata in
> > the first input script, allowing the miner of the genesis resolution to
> add a
> > special message. The pushdata MUST be castable to a true boolean.
> >
> > Why? Unlike the coinbase, this seems to create additional technical deb=
t
> with
> > no apparent purpose. Better to just have a consensus rule every input
> must be
> > null.
> >
> >> The resolution transaction's version MUST be set to the uint32 max
> (`2^32 -
> > 1`).
> >
> > Transaction versions are signed, so I assume this is actually simply -1=
.
> > (While signed transaction versions seemed silly to me, using it for
> special
> > cases like this actually makes sense.)
> >
> >> ### Exiting the extension block
> >
> > Should specify that spending such an exit must use the resolution txid,
> not
> > the extblock's txid.
> >
> >> On the policy layer, transaction fees may be calculated by transaction
> cost
> > as well as additional size/legacy-sigops added to the canonical block
> due to
> > entering or exiting outputs.
> >
> > BIPs should not specify policy at all. Perhaps prefix "For the avoidanc=
e
> of
> > doubt:" to be clear that miners may perform any fee logic they like.
> >
> >> Transactions within the extended transaction vector MAY include a
> witness
> > vector using BIP141 transaction serialization.
> >
> > Since extblock transactions are all required to be segwit, why wouldn't
> this
> > be mandatory?
> >
> >> - BIP141's nested P2SH feature is no longer available, and no longer a
> > consensus rule.
> >
> > Note this makes adoption slower: wallets cannot use the extblock until
> the
> > economy has updated to support segwit-native addresses.
> >
> >> To reduce the chance of having redeem scripts which simply allow for
> garbage
> > data in the witness vector, every 73 bytes in the serialized witness
> vector is
> > worth 1 additional point.
> >
> > Please explain why 73 bytes in Rationale.
> >
> >> This leaves room for 7 future soft-fork upgrades to relax DoS limits.
> >
> > How so? Please explain.
> >
> >> A consensus dust threshold is now enforced within the extension block.
> >
> > Why?
> >
> >> If the second highest transaction version bit (30th bit) is set to to
> `1`
> > within an extension block transaction, an extra 700-bytes is reserved o=
n
> the
> > transaction space used up in the block.
> >
> > Why wouldn't users set this on all transactions?
> >
> >> `default_witness_commitment` has been renamed to
> > `default_extension_commitment` and includes the extension block
> commitment
> > script.
> >
> > `default_witness_commitment` was never part of the GBT spec. At least
> describe
> > what this new key is.
> >
> >> - Deployment name: `extblk` (appears as `!extblk` in GBT).
> >
> > Should be just `extblk` if backward compatibility is supported (and
> `!extblk`
> > when not).
> >
> >> The "deactivation" deployment's start time...
> >
> > What about timeout? None? To continue the extension block, must it be
> > deactivated and reactivated in parallel?
> >
> >
> > _______________________________________________
> > 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
>

--94eb2c07de54aa0b49054c6be310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Y&#39;all,=C2=A0</div><div><br></div><div>Tha=
nks to luke-jr and jl2012 for publishing your analysis of the</div><div>xbl=
ocks proposal. I&#39;d like to also present some analysis but instead focus=
</div><div>on the professed LN safety enhancing scheme in the proposal. It&=
#39;s a bit</div><div>underspecified, so I&#39;ve taken the liberty of extr=
apolating a bit to fill</div><div>in the gaps to the point that I can analy=
ze it.</div><div><br></div><div>TLDR; The xblock proposal includes a sub-pr=
oposal for LN which is</div><div>essentially a block-size decrease for each=
 open channel within the network.</div><div>This decrease reserves space in=
 blocks to allow honest parties guaranteed</div><div>space in the blocks to=
 punish dishonest channel counter parties. As a result</div><div>the block =
size is permanently decreased for each channel open. Some may</div><div>con=
sider this cost prohibitively high.</div><div><br></div><div>&gt;&gt; If th=
e second highest transaction version bit (30th bit) is set to to `1`</div><=
div>&gt;&gt; within an extension block transaction, an extra 700-bytes is r=
eserved on</div><div>&gt;&gt; the transaction space used up in the block.</=
div><div><br></div><div>&gt; Why wouldn&#39;t users set this on all transac=
tions?</div><div><br></div><div>As the proposal stands now, it seems that u=
sers _are_ able to unilaterally</div><div>use this for all their Bitcoin tr=
ansactions, as there&#39;s no additional cost</div><div>to using the smart-=
contract safety feature outlined in the proposal.=C2=A0</div><div><br></div=
><div>The new safety measures proposed near the end of this xblock proposal=
</div><div>could itself consume a dedicated document outlining the prior ba=
ckground,</div><div>context, and implications of this new safety feature. T=
hroughout the rest</div><div>of this post, I&#39;ll be referring to the sch=
eme as a Pre-Allocated</div><div>Smart-contract Dispute arena (PASDA, chose=
n because it sounds kinda like</div><div>&quot;pasta&quot;, which brings me=
 many keks). It&#39;s rather insufficiently described and</div><div>under s=
pecified as it stands in the proposal. As a result, if one doesn&#39;t</div=
><div>have the necessary prior context, it might&#39;ve been skipped over e=
ntirely</div><div>as it&#39;s difficult to extract the sub-proposal from th=
e greater proposal. I</div><div>think I possess the necessary prior context=
 required to required to</div><div>properly analyze the sub-proposal. As a =
result, I would like to illuminate</div><div>the readers of the ML so y&#39=
;all may also be able to evaluate this</div><div>sub-proposal independently=
.</div><div><br></div><div><br></div><div>## Background</div><div><br></div=
><div>First, some necessary background. Within LN as it exists today there =
is</div><div>one particularly nasty systematic risk related to blockchain a=
vailability</div><div>in the case of a channel dispute. This risk is clearl=
y outlined in the</div><div>original white paper, and in my opinion a satis=
factory solution to the</div><div>risks which safe guard the use of very hi=
gh-value channels has yet to be</div><div>presented.=C2=A0</div><div><br></=
div><div><br></div><div>### Chain Spam/Censorship Attack Vector</div><div><=
br></div><div>The attack vector mentioned in the original paper is a reoccu=
rring attack</div><div>in systems of this nature: DoS attacks. As it stands=
 today, if a channel</div><div>counterparty is able to (solely, or in colla=
boration with other attackers)</div><div>prevent one from committing a tran=
saction to the chain, they&#39;re able to</div><div>steal money from the ho=
nest participant in the channel. The attack</div><div>proceeds something li=
ke this:</div><div><br></div><div>=C2=A0 =C2=A0* Mallory opens a very large=
 channel with me.</div><div>=C2=A0 =C2=A0* We transfer money back and forth=
 in the channel as normal. The nature</div><div>=C2=A0 =C2=A0 =C2=A0of thes=
e transfers isn&#39;t very important. The commitment balances may</div><div=
>=C2=A0 =C2=A0 =C2=A0be modified due to Mallory making multi-hop payments t=
hrough my</div><div>=C2=A0 =C2=A0 =C2=A0channel, or possibly from Mallory d=
irectly purchasing some goods I</div><div>=C2=A0 =C2=A0 =C2=A0offer, paying=
 via the channel.</div><div>=C2=A0 =C2=A0* Let&#39;s call the current commi=
tment number state S_i. In the lifetime</div><div>=C2=A0 =C2=A0 =C2=A0of th=
e channel there may exist some state S_j (i &lt; j) s.t Mallory&#39;s</div>=
<div>=C2=A0 =C2=A0 =C2=A0balance in S_i, is larger than S_j.=C2=A0</div><di=
v>=C2=A0 =C2=A0* At this point, depending on the value of the channel&#39;s=
 time-based</div><div>=C2=A0 =C2=A0 =C2=A0security parameter (T) it may be =
possible for Mallory to broadcast</div><div>=C2=A0 =C2=A0 =C2=A0state S_i (=
which has been revoked), and prevent me being able to</div><div>=C2=A0 =C2=
=A0 =C2=A0include by my punishment transaction (PTX) within the blockchain.=
</div><div>=C2=A0 =C2=A0* If Mallory is able to incapacitate me for a perio=
d of time T, or</div><div>=C2=A0 =C2=A0 =C2=A0censor my transactions from t=
he chain (either selectively or via a</div><div>=C2=A0 =C2=A0 =C2=A0spam at=
tack), then at time K (K &gt; T + B, where B is the time the</div><div>=C2=
=A0 =C2=A0 =C2=A0commitment transaction was stamped in the chain), then she=
&#39;ll be free</div><div>=C2=A0 =C2=A0 =C2=A0to walk away with her settled=
 balance at state S_i. For the sake of</div><div>=C2=A0 =C2=A0 =C2=A0simpli=
city, we&#39;re ignoring HTLC&#39;s.</div><div>=C2=A0 =C2=A0* Mallory&#39;s=
 gain is the difference between the balance at state S_i and</div><div>=C2=
=A0 =C2=A0 =C2=A0S_j. Deepening on the gap between the states, my settled b=
alance at</div><div>=C2=A0 =C2=A0 =C2=A0state S_i and the her balance delta=
, she may be able to fully recoup</div><div>=C2=A0 =C2=A0 =C2=A0the funds s=
he initially place in the channel.</div><div><br></div><div><br></div><div>=
### The Role of Channel Reserves as Partial Mitigation</div><div><br></div>=
<div>A minor mitigation to this attack that&#39;s purely commitment transac=
tion</div><div>policy is to mandate that Mallory&#39;s balance in the chann=
el never dips</div><div>below some reserve value R. Otherwise, if at state =
S_j, Mallory has a</div><div>settled balance of 0 within he channel (all th=
e money if on my side), then</div><div>the attack outline above can under c=
ertain conditions be _costless_ from</div><div>her PoV. Replicate this simu=
ltaneously across the network in a synchronized</div><div>manner (possibly =
getting some help from your miner friends) and this</div><div>becomes a bit=
 of a problem (to say the least).</div><div><br></div><div>Taking this a st=
ep further another mitigation that&#39;s been proposed is to</div><div>also=
 use the channel reserve to implement a _ceiling_ on the maximum size</div>=
<div>of _any_ in flight HTLC. Similar to the scheme above, this is meant to=
</div><div>eliminate the possibility of a &quot;costless&quot; attack, as i=
f channel throughput</div><div>is artificially constrained, then the value =
of pending HTLC&#39;s isn&#39;t</div><div>enticing enough to launch a chann=
el breach attack.</div><div><br></div><div><br></div><div>### Analysis of A=
ttack Feasibility/Difficulty</div><div><br></div><div>The difficulty of the=
 attack is dependant on the time-denominated security</div><div>parameter T=
, and the adversaries ability to collude with miners. Purely</div><div>spam=
ming the chain given a very larger T value may be prohibitively</div><div>e=
xpensive for the attacker and their profit from launching the attack</div><=
div>would need to outweigh the cost in transaction fees and idle bitcoin</d=
iv><div>required to launch the attack. Considering the case of colluding wi=
th</div><div>miners, if mining is highly centralized (as it is now), then t=
hat may be a</div><div>more attractive attack avenue. In a world of highly =
decentralized mining</div><div>(let&#39;s say a lofty goal of no pool comma=
nding &gt; 5% of the hash power),</div><div>then the attack is much more di=
fficult.=C2=A0</div><div><br></div><div>(as an aside schemes that involve t=
ransactions committing to the inputs</div><div>they&#39;re spending and rev=
ealing them at a later date/block (committed</div><div>transactions) may ad=
dress the miner censorship attack vector)</div><div><br></div><div>Dependin=
g one&#39;s target use of channels, the individuals they open channels</div=
><div>with, the applications that run on top of the channels, the amount of=
</div><div>coins within the channel, and the choice of the time parameter T=
, the</div><div>attack outline above may or may not be an issue from your P=
oV.=C2=A0 However,</div><div>in order to realize LN&#39;s maximum potential=
 of being able to enter a</div><div>smart-contract with a complete stranger=
 on the internet trustlessly,</div><div>without fearing conditions that may=
 lead to monetary losses, the attack</div><div>vector should be mitigated i=
f possible.</div><div><br></div><div>In the words of The Architect of the M=
atrix (and referenced by Tadge at</div><div>his &quot;Level of LN&quot; tal=
k at Scaling Bitcoin Hong Kong: &quot;There are levels of</div><div>surviva=
l we are prepared to accept&quot;. There exist levels of LN and usage of</d=
iv><div>channels, that may not consider this a dire issue.</div><div><br></=
div><div>OK, with the necessary background and context laid out, I&#39;ll n=
ow analyze</div><div>the solution proposed within the greater xblock propos=
al, making a brief</div><div>detour to briefly described another proposed s=
olution.</div><div><br></div><div>### Timestop</div><div><br></div><div>A p=
rior proposed solution to the failure scenario described above is</div><div=
>what&#39;s known as &quot;time stop&quot;. This was proposed by gmaxwell a=
nd was briefly</div><div>touched upon in the original LN white paper. The m=
echanism of the</div><div>time-denominated security parameter T in today&#3=
9;s channel construction is</div><div>enforced using OpCheckSequenceVerify.=
 After broadcasting a commitment</div><div>transaction, all outputs paying =
to the broadcaster of the commitment are</div><div>encumbered with a relati=
ve time delay of T blocks, meaning they are unable</div><div>to claim the f=
unds until time T has elapsed. This time margin gives the</div><div>honest =
party an opportunity to broadcast their punishment transaction</div><div>if=
f, the broadcaster has broadcast a prior revoked state.=C2=A0</div><div><br=
></div><div>The idea of time stomp is to introduce a special sequence-locks=
 block</div><div>height to the system. This block height would increase wit=
h each block</div><div>along with the regular block height _unless_ the blo=
ck reaches a certain</div><div>sustained &quot;high water mark&quot;. As an=
 example, let&#39;s assume that when 3</div><div>blocks in row are above 75=
% capacity, then the sequence-lock clock stops</div><div>ticking.</div><div=
><br></div><div>The effect of this change is to morph the security risk int=
o simply a</div><div>postponement of the judgment within the contract. With=
 this, DoS attacks</div><div>simply delay the (seemingly) inevitable punish=
ment of the dishonest party</div><div>within the contract.=C2=A0</div><div>=
<br></div><div>Aside from some informal discussions and the brief section w=
ithin the</div><div>original white paper, many details of this proposal are=
 left</div><div>underspecified. For example: how do miners signal to full n=
odes that the</div><div>sequence-lock clock has stopped? What&#39;s the hig=
h water mark threshold? Can</div><div>it go on indefinitely? Should this fe=
ature be opt-in?=C2=A0</div><div><br></div><div>I think this proposal shoul=
d be considered in tandem with the proposal</div><div>within the xblock pro=
posal as both have a few unanswered questions that</div><div>need to be fur=
ther explored.</div><div><br></div><div>## Pre-Allocated Smart-Contract Dis=
pute Area (PASDA)</div><div><br></div><div>Aight, now to the LN enhancing p=
roposal that&#39;s buried within the</div><div>greater xblock proposal. Int=
roducing some new terminology, I&#39;ve been</div><div>calling this a: Pre-=
Allocated Smart-contract Dispute Arena or (PASDA) for</div><div>short. In a=
 nut shell, the key idea of the proposal is this: transactions</div><div>th=
at mark the commencement of a smart contract who&#39;s security depends on<=
/div><div>availability of block space for disputes are able to _pre allocat=
e_ a</div><div>section of the block that will _always_ be _reserved_ for di=
spute</div><div>transactions. With this, contracts is =C2=A0_guaranteed_ sp=
ace in blocks to</div><div>handle disputes in the case that the contract br=
eaks down. As an analogy:</div><div>when you enter in a contract with a con=
tractor to build your dream</div><div>kitchen, you _also_ go to a court and=
 reserve a 1-hour block in their</div><div>scheduled to handle a dispute _j=
ust in case_ one arises. In the event of a</div><div>peaceful resolution to=
 the contract, the space is freed up.</div><div><br></div><div>The descript=
ion in the paper is a bit light on the details, so I&#39;ll say up</div><di=
v>front that I&#39;m extrapolating w.r.t to some mechanisms of the construc=
tion.</div><div>However, I&#39;ve been involved in some private conversatio=
ns where the idea</div><div>was thrown around, so I think I have enough con=
text to _maybe_ fill in</div><div>some of the gaps in the proposal.</div><d=
iv><br></div><div>I&#39;ll now restate the proposal. Smart contract transac=
tions set a certain</div><div>bit in their version number. This bit indicat=
es that they wish to</div><div>pre-allocate N bytes in _all_ further blocks=
 _until_ the contract has been</div><div>reserved. In the specific context =
of payment channels, this means that</div><div>once a channel is open, unti=
l it has been closed, it _decreases_ the</div><div>available block size for=
 all other transactions. As this is a very</div><div>aggressive proposal I =
think the authors took advantage of the new design</div><div>space within x=
blocks to include something that may not be readily accepted</div><div>as a=
 modification to the rules of the main chain.</div><div><br></div><div>The =
concrete parameters chosen in the proposal are: each channel opening</div><=
div>transaction reserves 700-bytes within _each_ block in the chain until t=
he</div><div>transaction has been closed. This pre-allocation has the follo=
wing</div><div>constraint: a transaction can _only_ take advantage of this =
allocation iff</div><div>it&#39;s spending the _first_ output of a smart-co=
ntract transaction (has a</div><div>particular bit in the version set). Thi=
s means that only dispute</div><div>resolution transactions can utilize thi=
s space.=C2=A0</div><div><br></div><div>The proposal references two allocat=
ions, which I&#39;ve squinted very hard at</div><div>for half a day in an a=
ttempt to parse the rules governing them, but so far</div><div>I&#39;ve bee=
n unable to glean any further details. From my squinting, I</div><div>inter=
pret that half of the allocation is reserved for spending the</div><div>sel=
f-output of a transaction in the last 2016 blocks (two weeks) and the</div>=
<div>other half is dedicated to spending the first output of a commitment</=
div><div>transaction in the _same_ block.</div><div><br></div><div>I&#39;m =
unsure as to why these allocations are separate, and why they aren&#39;t</d=
iv><div>just combined into a single allocation.</div><div><br></div><div>##=
# Modification to LN Today</div><div><br></div><div>This change would requi=
re a slight modification to LN as it&#39;s currently</div><div>defined toda=
y. ATM, we use BIP 69 in order the inputs and outputs of a</div><div>transa=
ction. This is helpful as it lets us just send of signatures for new</div><=
div>states as both sides already know the order of the inputs and outputs.<=
/div><div>With PASDA, we&#39;d now need to omit the to-self-output (the out=
put in my</div><div>commitment transaction paying to myself my settled bala=
nce) from this</div><div>ordering and _always_ make it the first output (tx=
id:0).</div><div><br></div><div>The second change is that this proposal put=
s a ceiling on on the CSV value</div><div>allowed by any channel. All CSV d=
elays _must-weeks otherwise, they&#39;re</div><div>unable to take advantage=
 of the arena.</div><div><br></div><div>### Modifications to Bitcoin</div><=
div><br></div><div>In order to implement this within Bitcoin, a third utxo =
set (regular</div><div>block, xblock) must be maintained by all full nodes.=
 Alternatively, this</div><div>can just be a bit in the xblock utxo set. Th=
e implementation doesn&#39;t</div><div>really matter. Before attempting to =
pack transactions into a block, the</div><div>total allocation within the P=
ASDA utxo-set must be summed up, and</div><div>subtracted from the block si=
ze cap. Only transactions which validly spend</div><div>from one of these U=
TXO&#39;s are able to take advantage of the new space in</div><div>the bloc=
k.</div><div><br></div><div>## Analysis of PASDA</div><div><br></div><div>O=
K, now for some analysis. First, let&#39;s assume that transactions which</=
div><div>create PASDA UTXO&#39;s aren&#39;t subject to any additional const=
raints. If so,</div><div>then this means that _any_ transaction can freely =
create PASDA UTXO&#39;s and</div><div>_decrease_ the block size for _all_ t=
ransactions until the UTXO has been</div><div>spent. If my interpretation i=
s correct, then this introduces a new attack</div><div>vector which allows =
_anyone_ to nearly permanently decrease the block size</div><div>for all-ti=
me with next to zero additional cost. If this is correct, then</div><div>it=
 seems that miners have _zero_ incentive to _ever_ include a transaction</d=
iv><div>that creates a PASDA output in their blocks as it robs them of futu=
re</div><div>revenue and decreases the available capacity in the system, po=
ssibly</div><div>permanently proportionally to _each_ unspent PASDA output =
in the chain.</div><div><br></div><div>Alternatively, let&#39;s say the tra=
nsactions which create PASDA outputs</div><div>_must_ pay a disproportionat=
ely high fee in order to pay up front for</div><div>their consumption of th=
e size within all future blocks. If so, then a</div><div>question that aris=
es is: How large a fee? If the fee is very large, then</div><div>the utiliz=
ation of the smart-contract battling arena is only reserved to</div><div>ve=
ry high valued channels who can afford very high fees. This may be</div><di=
v>acceptable as if you have a $5 channel, then are you really at risk at</d=
iv><div>such a large scale attack on Bitcoin just to steal $5 from you? It&=
#39;s</div><div>important to note that many attacks on LN&#39;s contract re=
solution</div><div>capabilities are also a direct attack on Bitcoin. Howeve=
r, in a world of</div><div>dynamic fees, then it may be the case that the f=
ee paid 6 months ago is</div><div>now a measly fee an no longer covers the =
costs to miners (and even the</div><div>entire system...).</div><div><br></=
div><div>Finally, here&#39;s something I thought of earlier today that poss=
ibly</div><div>mitigates the downside from the PoV of the miners (everyone =
else must</div><div>still accept the costs of a permanent block size decrea=
se). Let&#39;s say that</div><div>in order to create a PASDA output fees ar=
e paid as normal. However, for</div><div>_each_ subsequent block, the parti=
cipants of the contract _must_ pay a</div><div>tribute to miners to account=
 for their loss in revenue due to the</div><div>reduction in block size. Es=
sentially, all PASDA outputs must pay _rent_</div><div>for their pre-alloca=
ted space. If rent isn&#39;t paid sufficiently and on-time,</div><div>then =
the pre-allocate arena space is revoked by miners. There&#39;re a few</div>=
<div>ways to construct this payment, but I&#39;ll leave that to follow up w=
ork as I</div><div>just want to shed some light on the PASDA and its implic=
ations.</div><div><br></div><div>## Conclusion</div><div><br></div><div>I&#=
39;ve attempted to fill in some gaps for y&#39;all w.r.t exactly what the</=
div><div>sub-proposal within the greater xblock proposal consists of and so=
me</div><div>possible implications. I&#39;d like to note that I&#39;ve take=
n the liberty of</div><div>filling on some gaps within the sub-proposal as =
only a single section</div><div>within the greater proposal has been alloca=
ted to it. PASDA itself could</div><div>likely fill up an entirely distinct=
 propsal by itself spanning several</div><div>pages. To the authors of the =
proposal: if my interpretation is inaccurate</div><div>please correct me as=
 I&#39;d also like to better understand the proposal. It&#39;s</div><div>po=
ssible that everything I&#39;ve said in this (now rather long) email is</di=
v><div>incorrect.</div><div><br></div><div>If you&#39;ve made it this far, =
thank you for taking the time out of your day</div><div>to consider my thou=
ghts. It&#39;s my hope that we can further analyze this</div><div>sub-propo=
sal in detail and discuss its construction as well as its</div><div>implica=
tions on smart-contracts like payment channels on top of Bitcoin.</div><div=
><br></div><div>PASDA purports to address one half of the systematic risks =
in LN by</div><div>possibly eliminating the DoS vector attack against LN. H=
owever, the costs</div><div>of PASDA are very high, and possibly prohibitiv=
ely so. In my opinion, the</div><div>second attack vector lies in the abili=
ty of miners to arbitrarily censor</div><div>transactions spending a partic=
ular output. Fungibility enhancing</div><div>techniques such as Committed T=
ransactions may be a viable path forward to</div><div>patch this attack vec=
tor.</div><div><br></div><div>-- roasbeef</div></div><div><br></div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 4, 2017 at 8:35 =
PM Johnson Lau via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">I feel particularly disappointed that wh=
ile this BIP is 80% similar to my proposal made 2 months ago ( <a href=3D"h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.=
html" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html</a> ),=
 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.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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 somethin=
g really ready for production use.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; This specification defines a method of increasing bitcoin transaction =
throughput without altering any existing consensus rules.<br class=3D"gmail=
_msg">
<br class=3D"gmail_msg">
Softforks by definition tighten consensus rules<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; There has been great debate regarding other ways of increasing transac=
tion throughput, with no proposed consensus-layer solutions that have prove=
n themselves to be particularly safe.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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 logica=
lly speaking if segwit is not safe, this BIP could only be worse. OTOH, seg=
wit also obviously increases tx throughput, although it may not be as much =
as some people wish to have.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; This specification refines many of Lau&#39;s ideas, and offers a much =
simpler method of tackling the value transfer issue, which, in Lau&#39;s pr=
oposal, was solved with consensus-layer UTXO selection.<br class=3D"gmail_m=
sg">
<br class=3D"gmail_msg">
The 2013 one is outdated. As the authors are not quoting it, not sure if th=
ey read my January proposal<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt;=C2=A0 extension block activation entails BIP141 activation.<br class=
=3D"gmail_msg">
<br class=3D"gmail_msg">
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<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; The merkle root is to be calculated as a merkle tree with all extensio=
n block txids and wtxids as the leaves.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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, y=
et 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 wtxi=
ds or it can=E2=80=99t reconstruct the tree<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Outputs signal to exit the extension block if the contained script is =
either a minimally encoded P2PKH or P2SH script.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
This hits the biggest question I asked in my January post: do you want to a=
llow direct exit payment to legacy addresses? As a block reorg will almost =
guarantee changing txid of the resolution tx, that will permanently invalid=
ate all the child txs based on the resolution tx. This is a significant cha=
nge to the current tx model. To fix this, you need to make exit outputs uns=
pendable 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 le=
gacy address directly, but sent to a new format address that only recognize=
d by new wallet, which understands the lock up requirement. This way, howev=
er, introduces friction and some fungibility issues, and I=E2=80=99d expect=
 people using cross chain atomic swap to exchange bitcoin and xbitcoin<br c=
lass=3D"gmail_msg">
<br class=3D"gmail_msg">
To summarise, my questions are:<br class=3D"gmail_msg">
1. Is it acceptable to have massive txid malleability and transaction chain=
 invalidation for every natural happening reorg?=C2=A0 Yes: the current spe=
c is ok; No: next question (I=E2=80=99d say no)<br class=3D"gmail_msg">
2. Is locking up exit outputs the best way to deal with the problem? (I tri=
ed really hard to find a better solution but failed)<br class=3D"gmail_msg"=
>
3. How long the lock-up period should be? Answer could be anywhere from 1 t=
o 100<br class=3D"gmail_msg">
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?)<br class=3D"gmail_msg">
5. Due to the fungibility issues, it may need a new name for the tokens in =
the ext-block<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Verification of transactions within the extension block shall enforce =
all currently deployed softforks, along with an extra BIP141-like ruleset.<=
br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock. Esp=
ecially, you don=E2=80=99t want to replicate the sighash bug to xblock. Als=
o, requires scriptSig to be always empty<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; This leaves room for 7 future soft-fork upgrades to relax DoS limits.<=
br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Why 7? There are 16 unused witness program versions<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Witness script hash v0 shall be worth the number of accurately counted=
 sigops in the redeem script, multiplied by a factor of 8.<br class=3D"gmai=
l_msg">
<br class=3D"gmail_msg">
There is a flaw here: witness script with no sigop will be counted as 0 and=
 have a lot free space<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; every 73 bytes in the serialized witness vector is worth 1 additional =
point.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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 pr=
ovide any =E2=80=9Cfree space=E2=80=9D in the block.<br class=3D"gmail_msg"=
>
<br class=3D"gmail_msg">
&gt; Currently defined witness programs (v0) are each worth 8 points. Unkno=
wn witness program outputs are worth 1 point. Any exiting output is always =
worth 8 points.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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 o=
utput. The overall objective is to limit the UTXO growth. The ext block sho=
uld be mainly for making transactions, not store of value (I=E2=80=99ll exp=
lain later)<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Dust Threshold<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
In general I think it=E2=80=99s ok, but I=E2=80=99d suggest a higher thresh=
old like 5000 satoshi. It may also combine the threshold with the output wi=
tness version, so unknown version may have a lower or no threshold. Alterna=
tively, it may start with a high threshold and leave a backdoor softfork to=
 reduce it.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Deactivation<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
It is a double-edged sword. While it is good for us to be able to discard a=
n unused chain, it may create really bad user experience and people may eve=
n lose money. For example, people may have opened Lightning channels and th=
ey 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 refr=
esh 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.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
=E2=80=94=E2=80=94=E2=80=94=E2=80=94<br class=3D"gmail_msg">
some general comments:<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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 BIP1=
41 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 possi=
ble. Ext block is more complicated than segwit. If it took dozens of develo=
pers a whole year to release segwit, I don=E2=80=99t see how ext block coul=
d become ready for production with less time and efforts.<br class=3D"gmail=
_msg">
<br class=3D"gmail_msg">
2. Another reason to make this BIP compatible with BIP141 is we also need m=
alleability fix in the main chain. As the xblock has a deactivation mechani=
sm, it can=E2=80=99t be used for longterm value storage.<br class=3D"gmail_=
msg">
<br class=3D"gmail_msg">
3. I think the size and cost limit of the xblock should be lower at the beg=
inning, and increases as we find it works smoothly. It could be a predefine=
d 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 t=
he size grows bigger.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; On 5 Apr 2017, at 02:03, Luke Dashjr via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br class=3D"gma=
il_msg">
&gt;<br class=3D"gmail_msg">
&gt; Recently there has been some discussion of an apparent work-in-progres=
s<br class=3D"gmail_msg">
&gt; extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor In=
dutny,<br class=3D"gmail_msg">
&gt; and Steven Pair. Since this hasn&#39;t been formally posted on the ML =
yet, perhaps<br class=3D"gmail_msg">
&gt; it is still in pre-draft stages and not quite ready for review, but in=
 light<br class=3D"gmail_msg">
&gt; of public interest, I think it is appropriate to open it to discussion=
, and<br class=3D"gmail_msg">
&gt; toward this end, I have reviewed the current revision.<br class=3D"gma=
il_msg">
&gt;<br class=3D"gmail_msg">
&gt; For reference, the WIP proposal itself is here:<br class=3D"gmail_msg"=
>
&gt;=C2=A0 =C2=A0 <a href=3D"https://github.com/tothemoon-org/extension-blo=
cks" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://githu=
b.com/tothemoon-org/extension-blocks</a><br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; =3D=3DOverall analysis &amp; comparison=3D=3D<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; This is a relatively complicated proposal, creating a lot of additiona=
l<br class=3D"gmail_msg">
&gt; technical debt and complexity in comparison to both BIP 141 and hardfo=
rks. It<br class=3D"gmail_msg">
&gt; offers no actual benefits beyond BIP 141 or hardforks, so seems irrati=
onal to<br class=3D"gmail_msg">
&gt; consider at face value. In fact, it fits much better the inaccurate cr=
iticisms<br class=3D"gmail_msg">
&gt; made by segwit detractors against BIP 141.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; That being said, this proposal is very interesting in construction and=
 is for<br class=3D"gmail_msg">
&gt; the most part technically sound. While ill-fit to merely making blocks=
 larger,<br class=3D"gmail_msg">
&gt; it may be an ideal fit for fundamentally different block designs such =
as<br class=3D"gmail_msg">
&gt; Rootstock and MimbleWimble in absence of decentralised non-integrated<=
br class=3D"gmail_msg">
&gt; sidechains (extension blocks are fundamentally sidechains tied into Bi=
tcoin<br class=3D"gmail_msg">
&gt; directly).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; =3D=3DFundamental problem=3D=3D<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Extension blocks are a risk of creating two classes of &quot;full node=
s&quot;: those<br class=3D"gmail_msg">
&gt; which verify the full block (and are therefore truly full nodes), and =
those<br class=3D"gmail_msg">
&gt; which only verify the &quot;base&quot; block. However, because the ext=
ension is<br class=3D"gmail_msg">
&gt; consensus-critical, the latter are in fact not full nodes at all, and =
are left<br class=3D"gmail_msg">
&gt; insecure like pseudo-SPV (not even real SPV) nodes. This technical nat=
ure is<br class=3D"gmail_msg">
&gt; of course true of a softfork as well, but softforks are intentionally =
designed<br class=3D"gmail_msg">
&gt; such that all nodes are capable of trivially upgrading, and there is n=
o<br class=3D"gmail_msg">
&gt; expectation for anyone to run with pre-softfork rules.<br class=3D"gma=
il_msg">
&gt;<br class=3D"gmail_msg">
&gt; In general, hardforks can provide the same benefits of an extension bl=
ock, but<br class=3D"gmail_msg">
&gt; without the false expectation and pointless complexity.<br class=3D"gm=
ail_msg">
&gt;<br class=3D"gmail_msg">
&gt; =3D=3DOther problems &amp; questions=3D=3D<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; These outpoints may not be spent inside the mempool (they must be =
redeemed<br class=3D"gmail_msg">
&gt; from the next resolution txid in reality).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; This breaks the ability to spend unconfirmed funds in the same block (=
as is<br class=3D"gmail_msg">
&gt; required for CPFP).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; The extension block&#39;s transaction count is not cryptographically c=
ommitted-to<br class=3D"gmail_msg">
&gt; anywhere. (This is an outstanding bug in Bitcoin today, but impractica=
l to<br class=3D"gmail_msg">
&gt; exploit in practice; however, exploiting it in an extension block may =
not be<br class=3D"gmail_msg">
&gt; as impractical, and it should be fixed given the opportunity.)<br clas=
s=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; The merkle root is to be calculated as a merkle tree with all exte=
nsion<br class=3D"gmail_msg">
&gt; block txids and wtxids as the leaves.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; This needs to elaborate how the merkle tree is constructed. Are all th=
e txids<br class=3D"gmail_msg">
&gt; followed by all the wtxids (tx hashes)? Are they alternated? Are txid =
and<br class=3D"gmail_msg">
&gt; wtxid trees built independently and merged at the tip?<br class=3D"gma=
il_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Output script code aside from witness programs, p2pkh or p2sh is c=
onsidered<br class=3D"gmail_msg">
&gt; invalid in extension blocks.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Why? This prevents extblock users from sending to bare multisig or oth=
er<br class=3D"gmail_msg">
&gt; various possible destinations. (While static address forms do not exis=
t for<br class=3D"gmail_msg">
&gt; other types, they can all be used by the payment protocol.)<br class=
=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Additionally, this forbids datacarrier (OP_RETURN), and forces spam to=
 create<br class=3D"gmail_msg">
&gt; unprovably-unspendable UTXOs. Is that intentional?<br class=3D"gmail_m=
sg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; The maximum extension size should be intentionally high.<br class=
=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; This has the same &quot;attacks can do more damage than ordinary benef=
it&quot; issue as<br class=3D"gmail_msg">
&gt; BIP141, but even more extreme since it is planned to be used for futur=
e size<br class=3D"gmail_msg">
&gt; increases.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Witness key hash v0 shall be worth 1 point, multiplied by a factor=
 of 8.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; What is a &quot;point&quot;? What does it mean multiplied by a factor =
of 8? Why not just<br class=3D"gmail_msg">
&gt; say &quot;8 points&quot;?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Witness script hash v0 shall be worth the number of accurately cou=
nted<br class=3D"gmail_msg">
&gt; sigops in the redeem script, multiplied by a factor of 8.<br class=3D"=
gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Please define &quot;accurately counted&quot; here. Is this using BIP16=
 static counting,<br class=3D"gmail_msg">
&gt; or accurately counting sigops during execution?<br class=3D"gmail_msg"=
>
&gt;<br class=3D"gmail_msg">
&gt;&gt; To reduce the chance of having redeem scripts which simply allow f=
or garbage<br class=3D"gmail_msg">
&gt; data in the witness vector, every 73 bytes in the serialized witness v=
ector is<br class=3D"gmail_msg">
&gt; worth 1 additional point.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Is the size rounded up or down? If down, 72-byte scripts will carry 0<=
br class=3D"gmail_msg">
&gt; points...)<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; =3D=3DTrivial &amp; process=3D=3D<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; BIPs must be in MediaWiki format, not Markdown. They should be submitt=
ed for<br class=3D"gmail_msg">
&gt; discussion to the bitcoin-dev mailing list, not social media and news.=
<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Layer: Consensus (soft-fork)<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Extension blocks are more of a hard-fork IMO.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; License: Public Domain<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; BIPs may not be &quot;public domain&quot; due to non-recognition in so=
me jurisdictions.<br class=3D"gmail_msg">
&gt; Can you agree on one or more of these?<br class=3D"gmail_msg">
&gt; <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0002.mediaw=
iki#Recommended_licenses" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"=
_blank">https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Reco=
mmended_licenses</a><br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; ## Abstract<br class=3D"gmail_msg">
&gt;&gt;<br class=3D"gmail_msg">
&gt;&gt; This specification defines a method of increasing bitcoin transact=
ion<br class=3D"gmail_msg">
&gt; throughput without altering any existing consensus rules.<br class=3D"=
gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; This is inaccurate. Even softforks alter consensus rules.<br class=3D"=
gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; ## Motivation<br class=3D"gmail_msg">
&gt;&gt;<br class=3D"gmail_msg">
&gt;&gt; Bitcoin retargetting ensures that the time in between mined blocks=
 will be<br class=3D"gmail_msg">
&gt; roughly 10 minutes. It is not possible to change this rule. There has =
been<br class=3D"gmail_msg">
&gt; great debate regarding other ways of increasing transaction throughput=
, with<br class=3D"gmail_msg">
&gt; no proposed consensus-layer solutions that have proven themselves to b=
e<br class=3D"gmail_msg">
&gt; particularly safe.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Block time seems entirely unrelated to this spec. Motivation is unclea=
r.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Extension blocks leverage several features of BIP141, BIP143, and =
BIP144 for<br class=3D"gmail_msg">
&gt; transaction opt-in, serialization, verification, and network services,=
 and as<br class=3D"gmail_msg">
&gt; such, extension block activation entails BIP141 activation.<br class=
=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; As stated in the next paragraph, the rules in BIP 141 are fundamentall=
y<br class=3D"gmail_msg">
&gt; incompatible with this one, so saying BIP 141 is activated is confusin=
gly<br class=3D"gmail_msg">
&gt; incorrect.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; This specification should be considered an extension and modificat=
ion to<br class=3D"gmail_msg">
&gt; these BIPs. Extension blocks are _not_ compatible with BIP141 in its c=
urrent<br class=3D"gmail_msg">
&gt; form, and will require a few minor additional rules.<br class=3D"gmail=
_msg">
&gt;<br class=3D"gmail_msg">
&gt; Extension blocks should be compatible with BIP 141, there doesn=E2=80=
=99t appear to be<br class=3D"gmail_msg">
&gt; any justification for not making them compatible.<br class=3D"gmail_ms=
g">
&gt;<br class=3D"gmail_msg">
&gt;&gt; This specification prescribes a way of fooling non-upgraded nodes =
into<br class=3D"gmail_msg">
&gt; believing the existing UTXO set is still behaving as they would expect=
.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; The UTXO set behaves fundamentally different to old nodes with this pr=
oposal,<br class=3D"gmail_msg">
&gt; albeit in a mostly compatible manner.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Note that canonical blocks containing entering outputs MUST contai=
n an<br class=3D"gmail_msg">
&gt; extension block commitment (all zeroes if nothing is present in the ex=
tension<br class=3D"gmail_msg">
&gt; block).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Please explain why in Rationale.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Coinbase outputs MUST NOT contain witness programs, as they cannot=
 be<br class=3D"gmail_msg">
&gt; sweeped by the resolution transaction due to previously existing conse=
nsus<br class=3D"gmail_msg">
&gt; rules.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Seems like an annoying technical debt. I wonder if it can be avoided.<=
br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; The genesis resolution transaction MAY also include a 1-100 byte p=
ushdata in<br class=3D"gmail_msg">
&gt; the first input script, allowing the miner of the genesis resolution t=
o add a<br class=3D"gmail_msg">
&gt; special message. The pushdata MUST be castable to a true boolean.<br c=
lass=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Why? Unlike the coinbase, this seems to create additional technical de=
bt with<br class=3D"gmail_msg">
&gt; no apparent purpose. Better to just have a consensus rule every input =
must be<br class=3D"gmail_msg">
&gt; null.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; The resolution transaction&#39;s version MUST be set to the uint32=
 max (`2^32 -<br class=3D"gmail_msg">
&gt; 1`).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Transaction versions are signed, so I assume this is actually simply -=
1.<br class=3D"gmail_msg">
&gt; (While signed transaction versions seemed silly to me, using it for sp=
ecial<br class=3D"gmail_msg">
&gt; cases like this actually makes sense.)<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; ### Exiting the extension block<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Should specify that spending such an exit must use the resolution txid=
, not<br class=3D"gmail_msg">
&gt; the extblock&#39;s txid.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; On the policy layer, transaction fees may be calculated by transac=
tion cost<br class=3D"gmail_msg">
&gt; as well as additional size/legacy-sigops added to the canonical block =
due to<br class=3D"gmail_msg">
&gt; entering or exiting outputs.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; BIPs should not specify policy at all. Perhaps prefix &quot;For the av=
oidance of<br class=3D"gmail_msg">
&gt; doubt:&quot; to be clear that miners may perform any fee logic they li=
ke.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; Transactions within the extended transaction vector MAY include a =
witness<br class=3D"gmail_msg">
&gt; vector using BIP141 transaction serialization.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Since extblock transactions are all required to be segwit, why wouldn&=
#39;t this<br class=3D"gmail_msg">
&gt; be mandatory?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; - BIP141&#39;s nested P2SH feature is no longer available, and no =
longer a<br class=3D"gmail_msg">
&gt; consensus rule.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Note this makes adoption slower: wallets cannot use the extblock until=
 the<br class=3D"gmail_msg">
&gt; economy has updated to support segwit-native addresses.<br class=3D"gm=
ail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; To reduce the chance of having redeem scripts which simply allow f=
or garbage<br class=3D"gmail_msg">
&gt; data in the witness vector, every 73 bytes in the serialized witness v=
ector is<br class=3D"gmail_msg">
&gt; worth 1 additional point.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Please explain why 73 bytes in Rationale.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; This leaves room for 7 future soft-fork upgrades to relax DoS limi=
ts.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; How so? Please explain.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; A consensus dust threshold is now enforced within the extension bl=
ock.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Why?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; If the second highest transaction version bit (30th bit) is set to=
 to `1`<br class=3D"gmail_msg">
&gt; within an extension block transaction, an extra 700-bytes is reserved =
on the<br class=3D"gmail_msg">
&gt; transaction space used up in the block.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Why wouldn&#39;t users set this on all transactions?<br class=3D"gmail=
_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; `default_witness_commitment` has been renamed to<br class=3D"gmail=
_msg">
&gt; `default_extension_commitment` and includes the extension block commit=
ment<br class=3D"gmail_msg">
&gt; script.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; `default_witness_commitment` was never part of the GBT spec. At least =
describe<br class=3D"gmail_msg">
&gt; what this new key is.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; - Deployment name: `extblk` (appears as `!extblk` in GBT).<br clas=
s=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Should be just `extblk` if backward compatibility is supported (and `!=
extblk`<br class=3D"gmail_msg">
&gt; when not).<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;&gt; The &quot;deactivation&quot; deployment&#39;s start time...<br cla=
ss=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; What about timeout? None? To continue the extension block, must it be<=
br class=3D"gmail_msg">
&gt; deactivated and reactivated in parallel?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; _______________________________________________<br class=3D"gmail_msg"=
>
&gt; bitcoin-dev mailing list<br class=3D"gmail_msg">
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmai=
l_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=
=3D"gmail_msg">
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg=
">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div>

--94eb2c07de54aa0b49054c6be310--