[Lightning-dev] LN without SegWit: less efficient or less secure?

[Anthony Towns]

On Mon, Jan 16, 2017 at 01:00:48PM +1030, Rusty Russell wrote:
> > Which one is more accurate? Is the security problems only related to having
> > to watch the blockchain? If yes, why cannot one outsource this job to a
> > server (e.g. the hypothetical server of your light-wallet) in level2?
> Yes, the problem is outsourcing.

I thought the big problem was setup; you can't setup a new channel with a
stranger on the internet if they can coordinate with a miner to prevent
you from being able to reclaim your funds. (I didn't think outsourcing
was anywhere near ready, let alone already being blocked by miners :)

I have an idea on that though, I think... The idea when we were looking at
BIP 62 as a solution (which would have still left signature malleability
as a problem) was to have only one side pay into the funding transaction,
so that the other side couldn't malleate it and prevent the inital
refund. ie:

 - Alice pays $X into an output redeemable by 2-of-2 multisig, Alice and Bob,
   signs it, works out the txid, but doesn't publish yet.
 - Alice asks Bob to sign a refund tx that spends that transaction giving $X
   back to Alice, with the usual HTLC behaviour so that it becomes unusable
   once the channel starts being used.
 - Once Bob does this and Alice is satisfied, Alice publishes the original
   $X tx and once it is in the blockchain the channel is open.

The problem is that if any third party malleability is possible, and
happens to Alice's original tx, then Bob's signature on the refund tx is
no longer useful, and unless Bob is kind enough to sign a new refund tx,
Alice has lost her money.

Given there's no cost to Bob doing this, and potentially some profit if
Bob can convince Alice to pay a 10% fee to get her money back (or even
just the joy of vandalism if you're a troll or hate the idea of lightning
or whatever), there could be lots of people filling the role of "Bob"
and it could be hard to find someone safe to open a channel with, and,
in effect, lightning isn't usable at all except with people you already
know and trust, which isn't very decentralised.

Anyway my idea on avoiding this scenario: rather than have the funding
transaction just have a single output and a fee, have two outputs and
zero fee, the first being the funding output, and the second just being
a P2PKH to yourself.  In a second transaction, pay the entire second
output as a fee, which will allow the unmalleated funding transaction to
be propagated and mined via CPFP.  Any malleated version of the first
transaction will then be highly unlikely to get mined (or propogated),
because it won't include any fees, and the second transaction won't be
valid anymore, and nobody else will be able to generate a transaction
that spends either output to help it get propogated.

For this to fail, your channel partner would need to conspire with
a miner, and the miner would have to be lucky enough to beat all the
honest miners, assuming you included a competitive fee.  That seems
pretty unlikely to me -- the miner would be giving up fee income now
for the hope of a blackmail payment later. You could mitigate that
further by giving channels an expiry time (ie, pay to (Alice and Bob) OR
(CLTV 2 months, Alice)) so that you'd be guaranteed to get your funds
back eventually. That makes blackmail and vandalism both hard and not
profitable, which I think should be enough to make it vanishingly rare.

So I /think/ that's actually sufficient to get lightning working reliably
on *today's* bitcoin blockchain, even prior to segwit activating?

(If you wanted to partner with a couple of miners and submit transactions
directly, paying for them out of band, you could avoid the CPFP step too,
but that wouldn't be at all decentralised)

(If both Alice and Bob separately setup funding transactions, once they're
in the blockchain, they can be combined to fund a single channel as far
as I can see)

(I might be mistaken, but I don't see "ancestor feerate" mentioned in the
Bitcoin Unlimited git history and CPFP was a 0.13.0 feature, so I think
that means that Bitcoin Unlimited miners won't mine CPFP transactions,
and thus, with the approach outlined above, wouldn't mine transactions
for people setting up lightning channels. So I think this gives everyone
what they want? :)

Cheers,
aj