Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-16 📝 Original message: On 16 January 2017 at ...
📅 Original date posted:2017-01-16
📝 Original message:
On 16 January 2017 at 14:31, Anthony Towns <aj at erisian.com.au> wrote:
> 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.
>
But I thought this problem was already solved by using OP_CLTV/OP_CSV
-style channels instead of Spillman-style ones?
See:
http://bitcoin.stackexchange.com/a/48546/2751
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/ac47140c/attachment-0001.html>;
📝 Original message:
On 16 January 2017 at 14:31, Anthony Towns <aj at erisian.com.au> wrote:
> 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.
>
But I thought this problem was already solved by using OP_CLTV/OP_CSV
-style channels instead of Spillman-style ones?
See:
http://bitcoin.stackexchange.com/a/48546/2751
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/ac47140c/attachment-0001.html>;