Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Christopher Jeffrey via bitcoin-dev]

> To make it completely transparent to unupgraded wallets, the return outputs 
> have to be sent to something that is non-standard today, i.e. not P2PK, 
> P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.

Johnson,

I feel that's not as much of an issue with v0 witness programs. Segwit
isn't activated yet, and segwit-capable wallets aren't as widely
deployed for production. Not to mention, they're all going to require
further development anyway: the address serialization for witness
programs only became a BIP this week. No segwit wallets should ever be
planning to receive money to naked witness programs right now, since
addresses are for it aren't even available.

I think we have the benefit of timing here. The state of segwit wallet
development incidentally creates a window of time where this maturity
rule can be implemented.

On Wed, May 10, 2017 at 01:56:28AM +0800, Johnson Lau wrote:
> To make it completely transparent to unupgraded wallets, the return outputs 
> have to be sent to something that is non-standard today, i.e. not P2PK, 
> P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
>
> Mainchain segwit is particularly important here, as that allows atomic swap 
> between the bitcoin and xbitcoin. Only services with high liquidity 
> (exchanges, payment processors) would need to occasionally settle between the 
> chains.
>
>
> > On 9 May 2017, at 08:56, Christopher Jeffrey  wrote:
> >
> > Johnson,
> >
> > Yeah, I do still see the issue. I think there are still some reasonable
> > ways to mitigate it.
> >
> > I've started revising the extension block specification/code to coexist
> > with mainchain segwit. I think the benefit of this is that we can
> > require exiting outputs to only be witness programs. Presumably segwit
> > wallets will be more likely to be aware of a new output maturity rule
> > (I've opened a PR[1] which describes this in greater detail). I think
> > this probably reduces the likelihood of the legacy wallet issue,
> > assuming most segwit-supporting wallets would implement this rule before
> > the activation of segwit.
> >
> > What's your opinion on whether this would have a great enough effect to
> > prevent the legacy wallet issue? I think switching to witness programs
> > only may be a good balance between fungibility and backward-compat,
> > probably better all around than creating a whole new
> > addr-type/wit-program just for exits.
> >
> > [1] https://github.com/tothemoon-org/extension-blocks/pull/16 
> > 
> >
>

--
Christopher Jeffrey (JJ) 
CTO & Bitcoin Menace, purse.io
https://github.com/chjj


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Johnson Lau via bitcoin-dev]

To make it completely transparent to unupgraded wallets, the return outputs 
have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH, 
P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.

Mainchain segwit is particularly important here, as that allows atomic swap 
between the bitcoin and xbitcoin. Only services with high liquidity (exchanges, 
payment processors) would need to occasionally settle between the chains.


> On 9 May 2017, at 08:56, Christopher Jeffrey  wrote:
> 
> Johnson,
> 
> Yeah, I do still see the issue. I think there are still some reasonable
> ways to mitigate it.
> 
> I've started revising the extension block specification/code to coexist
> with mainchain segwit. I think the benefit of this is that we can
> require exiting outputs to only be witness programs. Presumably segwit
> wallets will be more likely to be aware of a new output maturity rule
> (I've opened a PR[1] which describes this in greater detail). I think
> this probably reduces the likelihood of the legacy wallet issue,
> assuming most segwit-supporting wallets would implement this rule before
> the activation of segwit.
> 
> What's your opinion on whether this would have a great enough effect to
> prevent the legacy wallet issue? I think switching to witness programs
> only may be a good balance between fungibility and backward-compat,
> probably better all around than creating a whole new
> addr-type/wit-program just for exits.
> 
> [1] https://github.com/tothemoon-org/extension-blocks/pull/16 
> 
> 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Christopher Jeffrey via bitcoin-dev]

Johnson,

Yeah, I do still see the issue. I think there are still some reasonable
ways to mitigate it.

I've started revising the extension block specification/code to coexist
with mainchain segwit. I think the benefit of this is that we can
require exiting outputs to only be witness programs. Presumably segwit
wallets will be more likely to be aware of a new output maturity rule
(I've opened a PR[1] which describes this in greater detail). I think
this probably reduces the likelihood of the legacy wallet issue,
assuming most segwit-supporting wallets would implement this rule before
the activation of segwit.

What's your opinion on whether this would have a great enough effect to
prevent the legacy wallet issue? I think switching to witness programs
only may be a good balance between fungibility and backward-compat,
probably better all around than creating a whole new
addr-type/wit-program just for exits.

[1] https://github.com/tothemoon-org/extension-blocks/pull/16

On Mon, Apr 10, 2017 at 06:14:36PM +0800, Johnson Lau wrote:
>
> > On 6 Apr 2017, at 01:43, Christopher Jeffrey  wrote:
> >
> >
> >> 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’t 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’d expect people using
> >> cross chain atomic swap to exchange bitcoin and xbitcoin
> >
> > Yes, this issue is probably the biggest edge case in the proposal.
> >
> > I think there's two possible solutions:
> >
> > First solution:
> >
> > Like you said, add a maturity requirement for exiting outputs. Likely
> > lower than coinbase's 100 block requirement. To solve the issue of
> > non-upgraded wallets not being aware of this rule and spending early,
> > have upgraded mempool implementations accept/relay txs that contain
> > early spends of exits, but not mine them until they are mature. This way
> > non-upgraded wallets do not end up broadcasting transactions that are
> > considered invalid to the rest of the network.
>
> This won’t solve the problem. Think about the following conversation:
>
> Alice (not upgraded): Please pay 1 BTC to my address 1ALicExyz
> Bob (upgraded): ok, paid, please check
>
> 10 minutes later
>
> Alice: received and confirmed, thanks!
>
> 5 minutes later:
>
> Carol (not upgraded): Please pay 0.5BTC to my address 3CaroLXXX
> Alice: paid, please check
>
> 1 hour later:
>
> Carol: it’s not confirmed. Have you paid enough fees?
> Alice: ok, I’ll RBF/CPFP it
>
> 2 hours later:
>
> Carol: it’s still not confirmed.
> Alice: I have already paid double fees. Maybe the network is congested and I 
> need to pay more…..
>
> Repeat until the lock up period ends.
>
> So this so-called “softfork” actually made non-upgraded wallet totally 
> unusable. If failed to meet the very important requirement of a softfork: 
> backward compatibility
>
> More discussion:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013985.html
>  
> 
>
>
> >
> > Depending on how wallets handle reorgs, a non-upgraded wallet may put
> > reorg'd spend chains from exits back into an unconfirmed state, when in
> > reality they should probably delete them or mark them conflicted in some
> > way. This may be an acceptable compromise as the wallet will still see
> > the funds as unconfirmed when they really don't exist anymore, but maybe
> > unconfirmed is good enough. Users are pretty used to dropping
> > non-confirming txs from their wallet, and this is much better than
> > legacy wallets seeing there funds as confirmed when they could be
> > permanently reorged out at any moment.
> >
> > Second solution:
> >
> > Move all exiting outputs to the coinbase. This will enforce a 100 block
> > maturity requirement and non-upgraded wallets will be aware of this.
>
> This is also unacceptable.
>
> When someone says "Please pay 1 BTC to my address 1ALicExyz”, no one 
> anticipates being paid by a coinbase output. Some exchanges like btc-e 
> explicitly reject coinbase payment.
>
> Such deterioration in user experience is unacceptable. It basically forces 
> everyone to upgrade, i.e. a hardfork with soft fork’s skin
>
>
>
> >
> > The first solution might require more implementation, but 

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Luke Dashjr via bitcoin-dev]

On Wednesday, April 05, 2017 4:54:05 PM Christopher Jeffrey via bitcoin-dev 
wrote:
> There's understandable confusion about this, but this proposal is not
> meant to be a BIP.

Oh? If this was not meant to be a Bitcoin Improvement Proposal, perhaps you 
should clarify somewhere what altcoin you are proposing it for. As it stands, 
it certainly did read much like it was meant to be a BIP, and apparently many 
others thought so as well.

Admittedly, the bitcoin-dev ML isn't the place for altcoin discussions, and 
I'm not particularly interested in spending my time aiding altcoins, so I'll 
just end the conversation here until someone re-proposes something similar for 
Bitcoin.

Sorry for confusing the nature of your work,

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Christopher Jeffrey via bitcoin-dev]

Hi Johnson,

Really appreciate the comments. I know this idea is your baby.

> so the authors don’t 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.

Segwit wasn't considered to be a part of that statement. It was
referring to the numerous hardfork proposals we've seen over the past
few years. Segwit is safe, but wouldn't be a comparable block size
increase to what ext. blocks could potentially offer.

> 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

Agreed. Needs to be reworded as it currently stands. Though, I suppose
it would be possible to allow for compatibility with segwit in the
mainchain if we utilize your idea of using a separate wit. program
versions for the extension block. A slightly minor change to the spec,
just a big change to the reference impl. code. It is doable.

> 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’t 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’d expect people using
> cross chain atomic swap to exchange bitcoin and xbitcoin

Yes, this issue is probably the biggest edge case in the proposal.

I think there's two possible solutions:

First solution:

Like you said, add a maturity requirement for exiting outputs. Likely
lower than coinbase's 100 block requirement. To solve the issue of
non-upgraded wallets not being aware of this rule and spending early,
have upgraded mempool implementations accept/relay txs that contain
early spends of exits, but not mine them until they are mature. This way
non-upgraded wallets do not end up broadcasting transactions that are
considered invalid to the rest of the network.

Depending on how wallets handle reorgs, a non-upgraded wallet may put
reorg'd spend chains from exits back into an unconfirmed state, when in
reality they should probably delete them or mark them conflicted in some
way. This may be an acceptable compromise as the wallet will still see
the funds as unconfirmed when they really don't exist anymore, but maybe
unconfirmed is good enough. Users are pretty used to dropping
non-confirming txs from their wallet, and this is much better than
legacy wallets seeing there funds as confirmed when they could be
permanently reorged out at any moment.

Second solution:

Move all exiting outputs to the coinbase. This will enforce a 100 block
maturity requirement and non-upgraded wallets will be aware of this.

The first solution might require more implementation, but allows more
flexibility with the maturity requirement. The second solution is
possibly simpler, but sticks to a hard 100 block limit.

> 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’d say no)

Answered above.

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

You've probably thought about this more than anyone, so I'd say yes, it
may be the only way. Painful, but necessary.

> 3. How long the lock-up period should be? Answer could be anywhere
> from 1 to 100

I imagine having something lower than 100 would be preferable to users,
maybe somewhere in the 5 to 15 range. A 15 block reorg on mainnet is
seriously unlikely unless something strange is happening. A 5 block
reorg is still pretty unlikely, but possible. The coinbase solution only
allows for 100 blocks though.

> 4. With a lock-up period, should it allow direct exit to legacy
> address? (I think it’s ok if the lock-up is short, like 1-2 block. But
> is that safe enough?)

I think so. Adding a kind of special address probably creates more
issues than it solves.

> 5. Due to the fungibility issues, it may need a new name for the
> tokens in the ext-block

I suppose the market will decide whether that's the case.

It's worth noting, if segwit is not activated on the mainchain, it
creates a much bigger incentive to 

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Johnson Lau via bitcoin-dev]

> On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun  wrote:
> 
> 
> 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. 
> 
> 

Why so? It seems you are describing it as a softfork. With hardfork or 
extension block, a new rule could simply grant extra space when the tagged UTXO 
is spent. So if the usual block size limit is 1MB, when the special UTXO is 
made, the block size limit decreases to 1MB-700 byte, and the user has to pay 
for that 700 byte. When it is spent, the block size will become 1MB+700 byte.

But miners or even users may abuse this system: they may try to claim all the 
unused space when the blocks are not congested, or when they are mining empty 
block, and sell those tagged UTXO later. So I think we need to limit the 
reservable space in each block, and deduct more space than it is reserved. For 
example, if 700 bytes are reserved, the deduction has to be 1400 byte.

With BIP68, there are 8 unused bits in nSequence. We may use a few bits to let 
users to fine tune the space they want to reserve. Maybe 1 = 256 bytes

I think this is an interesting idea to explorer and I’d like to include this in 
my hardfork proposal.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Christopher Jeffrey via bitcoin-dev]

Hi Luke,

Thank you for the review. Many of these points should definitely be
addressed in the spec. Although extension blocks has working code, the
spec is currently still in a draft state now and could really use all
the feedback it can get. A few rules are still up in the air before we
setup a public testnet for it.

There's understandable confusion about this, but this proposal is not
meant to be a BIP. If it were meant to be a BIP, we still might not have
even submitted it yet as it needs a bit more revision still.

I'm just going to go over a lot of these and explain the reasoning.

> This breaks the ability to spend unconfirmed funds in the same block
> (as is required for CPFP).

Yeah, child-pays-for-parent is practically impossible for exiting
outputs. I don't see a good way around this. We tried to figure out a
decent solution while initially drafting this. It's possible with tons
of trickery, but likely not worth it.

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

Yes. The merkle commitments are something we could definitely improve.
Open to suggestions. Personally, I don't consider myself a merkle
expert.

> 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 and wtxid trees built independently and merged at the tip?

As of right now, the reference implementation uses the former, but
again, the merkle commitments are something up in the air. It'd be nice
to keep it as flexible as possible for SPV proofs on either the txids or
wxtids.

> Why? This prevents extblock users from sending to bare multisig or
> other various possible destinations. (While static address forms do
> not exist for other types, they can all be used by the payment
> protocol.)

Requiring only p2pkh and p2sh for exits reduces the possibility of more
UTXO set size bloat (at least slightly). Non-standard scripts are a
problem since they cannot be compressed for storage. I don't see it as
important to allow naked multisig outputs. Currently, if users wanted to
use a naked multisig (why?), they can always use the 1mb chain directly.

> Additionally, this forbids datacarrier (OP_RETURN), and forces spam to
> create unprovably-unspendable UTXOs. Is that intentional?

All outputs within the extension block are meant to be witness programs.
This was done for simplicity. The 1mb chain is still usable for any
OP_RETURNs committed to the chain. More thought on this would be good
though.

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

> What is a "point"? What does it mean multiplied by a factor of 8? Why
> not just say "8 points"?

Just for consistency of wording.

The notion of cost creates a system of points which are multiplied by a
factor chosen by the witness program version. Unknown witness programs
have a factor of 1. If, in the future, we soft-fork in a new witness
program version, its chosen factor could be 7 or 6. The idea being,
future versions could add less "cost" to the block, allowing for
relaxing dos limits over time via soft-fork.

I would much rather have people arguing over whether to soft-fork dos
limits than whether to hard-fork dos limits.

So the idea here is, we have a hard limit (say 6mb) for quick sanity
checking and DoS prevention, and a soft-forkable soft limit (e.g. 2mb).

Having unknown witness program versions be worth only 1 point does
enable the possibility that a worst case block could be up to the "hard"
max extension size limit. This is also a possibility with segwit, but
yes, less severe with segwit assuming the max ext. block size is above
3mb.

More discussion and running of numbers is probably necessary before we
come up with optimal limits here.

> Please define "accurately counted" here. Is this using BIP16 static
> counting, or accurately counting sigops during execution?

It's meant to refer to BIP16 static counting. I believe the actual
argument passed to the function in Bitcoin Core is called `fAccurate`.
Many other implementations use the same terminology. The counting during
execution proposed by Gavin's hardfork BIP isn't widely implemented as
far as I know.

> Is the size rounded up or down? If down, 72-byte scripts will carry 0
> points...)

Rounded up. The code included this earlier, but I took the whole
weighing against size out temporarily. Will be updated to match the
spec.

> BIPs must be in MediaWiki format, not Markdown. They should be
> submitted for discussion to the bitcoin-dev mailing list, not social
> media and news.

Yeah, that's sort 

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Greg Sanders via bitcoin-dev]

I'd appreciate the authors chiming in, but I read the PASDA differently:

1) If a transaction is mined with a certain bit set, it reserves 700 bytes
for that particular block.
2) In that space, 2 transactions may happen:
a) First, a transaction penalizing the "parent" transaction for fraud by
spending the funds immediately
b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
window

This means during systematic flooding of closing transactions by
Goldfinger, vigilant watchers of their channels can immediately punish the
fraud in the same block using (a), and if they are unable to, need to find
space within two weeks in (b).

This is really in the LN weeds however, so I'll refrain from evaluating the
efficacy of such a solution.

On Wed, Apr 5, 2017 at 10:05 AM, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> result
> 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, 

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Olaoluwa Osuntokun via bitcoin-dev]

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

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Luke Dashjr via bitcoin-dev]

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

==Overall analysis & comparison==

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 as 
Rootstock and MimbleWimble in absence of decentralised non-integrated 
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin 
directly).

==Fundamental problem==

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.

==Other problems & questions==

> 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 (as 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 extension 
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 and 
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 other 
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...)

==Trivial & process==

BIPs must be in MediaWiki format, not Markdown. They should be submitted 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#Recommended_licenses

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

This is inaccurate. Even