Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Chris Belcher via bitcoin-dev
Hello list,

This proposal is very cool. It is very useful to have a coinswap scheme
requiring only two transactions.

As well as improving the scalability of the system by saving block
space, it also improves privacy because the coins could stay unspend for
a long time, potentially indefinitely. While in the original coinswap
proposal an analyst of the chain would always see a funding transaction
followed closely in time by a success transaction, and this could be
used as a fingerprint.

On 11/05/2020 18:50, Ruben Somsen via bitcoin-dev wrote:
> Hi ZmnSCPxj,
> 
> Thanks for your feedback :)
>
>> CoinSwap for privacy is practically a "cross" chain atomic swap with the 
>> same chain and token for both sides of the swap, see also this set of ideas: 
>> https://github.com/AdamISZ/CoinSwapCS/issues/53
>>
>> "Instead, Bob simply hands secretBob to Alice" is basically the same as 
>> private key turnover
> 
> Thanks for the link. I will add it to the links at the bottom of the
> write-up, as I agree it's related. Do note there are a few key
> differences:
> 
> - The swap is set up in an "asymmetric" way with only timelocks on one
> side, so on the other side the swap *never* expires
> - The timelocks are set up in such a way that the swap does not expire
> unless Alice starts the relative timelock countdown (the revoke
> transaction)
> - This relative timelock setup comes practically for free, because the
> asymmetry naturally requires that kind of setup

You could create an old-style coinswap scheme using relative timelocks
(with OP_CSV). The original proposal uses absolute timelocks but there's
no reason relative timelocks can't be used instead, as long as the party
who starts with knowledge of the preimage has a timelock further away in
the future.

Using relative timelocks and private key handover for old-style
coinswaps would give us the same two-transaction effect and the
corresponding efficiency and privacy gains.

Of course we still don't get the effect that the swap on the other side
never expires.

A fun fact is that the idea of private key handover was mentioned as
early as 2016 in the original Lightning Network paper. The bottom of
page 27 says: "Instead  of disclosing the BR1a/BR1b signatures, it’s
also possible to just disclose the private keys to the counterparty.
This is more effective as described later in the key storage section".
Although it looks like nobody thought to apply it to coinswap or
realized the benefits.


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


Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread Chris Belcher via bitcoin-dev
On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> Trust-minimization of Bitcoin security model has always relied first and
>>> above on running a full-node. This current paradigm may be shifted by LN
>>> where fast, affordable, confidential, censorship-resistant payment
>> services
>>> may attract a lot of adoption without users running a full-node.
>>
>> No, it cannot be shifted. This would compromise Bitcoin itself, which for
>> security depends on the assumption that a supermajority of the economy is
>> verifying their incoming transactions using their own full node.
>>
> 
> Hi Luke,
> 
> I have heard this claim made several times but have never understood the
> argument behind it. The question I always have is: If I get scammed by not
> verifying my incoming transactions properly how can this affect anyone
> else? It's very unintuative.  I've been scammed several times in my life in
> fiat currency transactions but as far as I could tell it never negatively
> affected the currency overall!
> 
> The links you point and from what I've seen you say before refer to "miner
> control" as the culprit. My only thought is that this is because a light
> client could follow a dishonest majority of hash power chain. But this just
> brings me back to the question. If, instead of BTC, I get a payment in some
> miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> running a light client) that still seems to only to damage me. Where does
> the side effect onto others on the network come from?
> 
> Cheers,
> 
> LL
> 

Hello Lloyd,

The problem comes when a large part of the ecosystem gets scammed at
once, which is how such an attack would happen in practice.

For example, consider if bitcoin had 1 users. 10 of them use a full
node wallet while the other 9990 use an SPV wallet. If a miner attacked
the system by printing infinite bitcoins and spending coins without a
valid signature, then the 9990 SPV wallets would accept those fake coins
as payment, and trade the coins amongst themselves. After a time those
coins would likely be the ancestors of most active coins in the
9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
full-node-coin and SPV-coin.

Now the fraud miners may become well known, perhaps being published on
bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
incentive to be against any rollback. Their recent transactions would
disappear and they'd lose money. They would argue that they've already
been using the coin for a while, and it works perfectly fine, and anyway
a coin that can be spent in 9990 places is more useful than one that can
be spent in just 10 places. The SPV-wallet community might even decide
to use something like `invalidateblock` to make sure their SPV-coin
doesn't get reorg'd out of existence. There'd also likely be a social
attack, with every bitcoin community portal being flooded with bots and
shills advocating the merits of SPV-coin. This is not a hypothetical
because we already saw the same thing during the scalability conflict
2015-2017.

Before you know it, "Bitcoin" would become SPV-coin with inflation and
arbitrary seizure. Any normal user could download software called
"Bitcoin wallet" which they trust and have used before, but instead of
using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
backed by a full node, but that won't do much good to you when 9990
users happily use another coin as their medium of exchange.

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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj,

>If the shortened refund transaction exists (labeled "refund transaction
#1" in the SVG) then the same issue still occurs

Yes, but there is one crucial difference: at that point in the protocol
(Bob has the success transaction and then stops cooperating) Alice and Bob
both had the opportunity not to take that path. Bob could have sent the
success transaction, and Alice could have waited and sent the revoke
transaction. They would essentially be "colluding" to fail.

>Without the refund#1 in your proposal, Bob refusing cooperation after
Alice puts the BTC into lock for 3 days and 2 further onchain transactions

I'm not sure if I correctly understood what you're saying, but it's as
follows:

Refund #1 can only safely be used before the signed success tx is given to
Bob. The cost to Alice at this point if Bob aborts is two on-chain
transactions while Bob hasn't put anything on-chain yet.

Refund #2 needs to be used after Bob receives the signed success tx. The
cost to Alice is now three transactions, but Bob also went-on-chain by this
point, so causing this wasn't costless to Bob and is thus a similar failure
mode.

>my formulation allows any of the result transactions to be CPFP directly
by their beneficiaries

Yes, that is indeed very nice. The way I set it up, insufficient fees can
unfortunately cause delays, but they should not be able to cause losses.

>there is still an onlineness requirement in case Bob does not complete the
protocol

Yes, that is very much the design. Alice needs to be on time with claiming
her refund (and revealing her secret), otherwise Bob takes it.

>I have not seen the 2-tx variant video yet, as I prefer to read than listen

The video is not required, it just restates what is in the write-up. I
personally find it easier to understand concepts from video, but I seem to
be in the minority when I ask other devs about this. But let me reiterate
one part you might be confused about (though you probably mostly get it
already):

The online requirement I was alluding to doesn't expire, and is
specifically how the 2 tx SAS protocol is performed. Bob never broadcasts
the success transaction (unless he prefers not to have to be online, i.e.
the 3 tx SAS protocol) and instead Alice and Bob swap their keys: first Bob
hands over secretAlice, then Alice hands over her key. Now the swap is
complete, but Bob has to remain online to make sure Alice never attempts to
broadcast her refund tx. It doesn't expire either because of the relative
timelocks.

Just take a look at the slide 6m8s into the video:
https://youtu.be/TlCxpdNScCA?t=6m8s

I also agree with your observation that alternatively Bob can just spend
before the timelock expires.

>Regardless, the overall protocol of using 3 clauses in the swap, and
reusing the privkey as the payment secret demanded by the pointlocks, is
still a significant innovation.

I'm glad you like it :)

>In the context of CoinSwap, a proposal is that a CoinSwap server would
provide swapping service to incoming clients.

That is an excellent use case that takes good advantage of the asymmetry of
SAS. I completely agree with your observation that the "Bob" side is
perfect for servers (online and/or spending again soon) and the "Alice"
side is perfect for clients (settled in 1 tx). I similarly hope that this
may pave the way for a practical implementation of Payswap between
merchants and customers!

Cheers,
Ruben

On Tue, May 12, 2020 at 5:06 PM ZmnSCPxj  wrote:

> Good morning Ruben,
>
> > >Would this not work?
> >
> > I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
> >
> > Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> If the shortened refund transaction exists (labeled "refund transaction
> #1" in the SVG) then the same issue still occurs: after 1 day it is
> possible for either success or refund#1 to be broadcasted, leading to
> revelation of both secrets, leading to the same failure mode you described.
>
> Without the refund#1 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Richard,

> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your 
> concern as: A node without direct internet connectivity can not rely on an 
> opportunistically incentivized local network peer for blockchain information 
> because the off-grid node's direct LN peers could collude to not forward the 
> payment.

Correct.

> > > 2) a light client can query an ISP connected full node on the same 
> > > unmetered local WiFi network and exchange differences in block headers 
> > > opportunistically or pay for large missing ranges of headers, filters or 
> > > full blocks using a payment channel. Cost is reduced and privacy is 
> > > enhanced for the light client by not using a centralized ISP. Bandwidth 
> > > for running the full node can be amortized and subsidized by payments 
> > > from light clients who they resell data to.
> >
> > A relatively pointless observation, but it seems to me that:
> >
> > * The light client is requesting for validation information, because...
> > * ...its direct peers might be defrauding it, leading to...
> > * ...the money it *thinks* it has in its channels being valueless.
> >
> > Thus, if the light client opportunistically pays for validation information 
> > (whether full blocks, headers, or filters), the direct peers it has could 
> > just as easily not forward any payments, thus preventing the light client 
> > from paying for the validation information.
> >
> > Indeed, if the direct peer *is* defrauding the light client, the direct 
> > peer has no real incentive to actually forward *any* payments --- to do so 
> > would be to reduce the possible earnings it gets from defrauding the light 
> > client.
> > ("Simulating" the payments so that the light client will not suspect 
> > anything runs the risk that the light client will be able to forward all 
> > its money out of the channel, and the cheating peer is still potentially 
> > liable for any funds it originally had in the channel if it gets caught.)
>
> One question I had is: how can a malicious direct payment peer "simulate" a 
> successful payment made by an off-grid victim peer to an information source?  
> The censoring peer wouldn't be able to return the preimage for a payment they 
> failed to forward. Also, since the information provider and off-grid node can 
> presumably communicate via their local network connection, it would be 
> obvious if all of the victims LN peers were failing to forward payments 
> (whether maliciously or due to routing failures) to an information provider 
> they could otherwise communicate with.

Perhaps "simulate" is not quite the correct term.
Basically, if the eclipsing peer(s) are reasonably sure they have eclipsed the 
light client, then all funds in those channels are semantically theirs (they 
"0wn" the eclipsed light client).
Then anything the light node offers from those channels (which it thinks are 
its, but are now in reality owned by the eclipsing peer) has no value (the 
eclipsing node already 0wns the light node and all its funds, what can the 
light node offer to it?).
The eclipsing peer could still "simulate" what the light node expects of 
reality by pretending that the light node actually still owns funds in the 
channel (even though the eclipsing node has successfully stolen all those 
funds), and forward as normal to get the payment preimage/scalar.


> > What would work would be to use a system similar to watchtowers, wherein 
> > the validation-information-provider is prepaid and issues tokens that can 
> > be redeemed later.
> > But this is not suitable for opportunistic on-same-WiFi where, say, a 
> > laptop is running a validation-information-provider-for-payment program on 
> > the same WiFi as a light-client mobile phone, if we consider that the 
> > laptop and mobile may have never met before and may never meet again.
> > It would work if the laptop altruistically serves the blocks, but not if it 
> > were for (on-Lightning) payment.
>
> There's another problem if we can't rely on a recurring relationship with an 
> information provider besides not being able to prepay for validation 
> information doesn't make sense. We don't want an information provider to 
> collect payments for serving invalid information. Maybe for very small 
> payments this isn't a problem, but ideally validity could be coded into the 
> HTLC.
>
> For example, an alternative HTLC construct that only paid for valid 81 B 
> headers that hash to 32 B values with a number of leading zeros committed to 
> by the HTLC. It would make more economic sense for an internet gateway node 
> to serve valid mined header to nodes on their local WiFi network than to 
> create bogus ones with the same (high) amount of work.

If you are considering this for on-Lightning payments, do note that the 
alternative HTLC construct has to be known by every forwarding node, including 
the direct peer(s) of the light client, which are precisely the potential 
attackers on 

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> >Would this not work?
>
> I considered and rejected that model for the following reason: there are 
> moments where both Alice and Bob can claim the BTC. If they both attempt to 
> do so, it also reveals both secrets, causing the LTC to also be claimable by 
> both parties. This chaotic scenario is a failure mode that did not seem 
> acceptable to me. The revoke transaction was specifically added to mitigate 
> that issue (invalidating any attempt of Bob to claim the coins and reveal his 
> secret). That said, it doesn't particularly seem in either party's interest 
> wait until a moment where two timelocks become valid, so maybe it is not 
> quite as bad as I thought. However, it still means that the 
> incompetence/malevolence of one party can lead to losses for both parties. I 
> have my doubts a gain in privacy in the uncooperative case is worth that risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2, but 
> regardless, not having to watch the chain is probably more practical in many 
> cases. As an aside, if both chains support timelocks then we can ensure that 
> the more expensive chain only receives one transaction.

If the shortened refund transaction exists (labeled "refund transaction #1" in 
the SVG) then the same issue still occurs: after 1 day it is possible for 
either success or refund#1 to be broadcasted, leading to revelation of both 
secrets, leading to the same failure mode you described.

Without the refund#1 in your proposal, Bob refusing cooperation after Alice 
puts the BTC into lock for 3 days and 2 further onchain transactions (with the 
refund#2 transaction being relative-locked, meaning it cannot be used to CPFP 
the revoke transaction; my formulation allows any of the result transactions to 
be CPFP directly by their beneficiaries).

It seems to me that there is still an onlineness requirement in case Bob does 
not complete the protocol: once the revoke tx becomes valid an online Bob can 
cheat an offline Alice by broadcasting the revoke tx (which, if my 
understanding of the protocol is correct, the signatures are shared to both 
Alice and Bob).
So Alice needs to be online starting at 2 days to 3 days in order to ensure it 
reclaims it funds.

I have not seen the 2-tx variant video yet, as I prefer to read than listen, 
but I will also check it if I can find an opportunity.

Regardless, the overall protocol of using 3 clauses in the swap, and reusing 
the privkey as the payment secret demanded by the pointlocks, is still a 
significant innovation.



In the context of CoinSwap, a proposal is that a CoinSwap server would provide 
swapping service to incoming clients.
Using my counterproposal, the Bob position can be taken by the server and the 
Alice position taken by the client.
In this context, the L1 can be made reasonably close in the future and L2 far 
in the future, in which case Alice the client can be "weakly offline" most of 
the time until L2, and even in a protocol abort would be able to recover its 
funds.
If the protocol completes, the server Bob can claim its funds before L1, and 
(with knowledge of Alice[0]) can immediately put it in a new funding tx for a 
new incoming client before L1, which is a fine tradeoff for server Bob since 
presumably Bob is always online.

Regards,
ZmnSCPxj


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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi Lloyd,

>In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done!

Thanks for the kind praise, and for providing a summary of what you think
makes the protocol useful. Your different perspective is undoubtedly useful
for others who are trying to understand it.

>We might call this a "Forced Refund *TLC"

Good description, I like it.

>The advantages that Ruben's two tx protocol has over this is that
timelocks and monitoring is only needed on one of the chains.

Well put, and I agree with your point that the traditional 4 tx protocol
can also be turned into 2 tx with an online requirement. One minor thing to
add is that this would make the 4 tx protocol more clunky in the
non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no
cost.

Cheers,
Ruben

On Tue, May 12, 2020 at 1:30 PM Ruben Somsen  wrote:

> Hi ZmnSCPxj,
>
> >Would this not work?
>
> I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> >if relative locktimes are used as often as absolute locktimes for
> block-sniping-prevention and a decent Scriptless Script system, then all
> protocol aborts should be doable with no information leaks
>
> I see your point, interesting observation.
>
> >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO
> on the LTC side would not be in that HD, and if Alice wants to cold-store
> the LTC, it should move the money as well into an HD pubkey.
>
> Agreed, I had that listed as one of the disadvantages: "Access to money is
> contingent on remembering secrets (backup complexity)"
>
> Cheers,
> Ruben
>
>
> On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier 
> wrote:
>
>> A quick correction to my post:
>>
>>>
>>> Here's where the truly novel part comes in. Ruben solves this by
>>> extending the standard *TLC contract:
>>> 1. Bob redeem with secret
>>> 2. Alice refund after T1
>>> 3. Bob redeem without secret after T2
>>>
>>> This is actually:
>>
>> 1. Bob redeem with redeem secret
>> 2. Alice refund after T1 with refund secret
>> 3. Bob redeem without secret after T2
>>
>> The fact that Alice reveals a secret when she refunds is crucial.
>>
>> LL
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj,

>Would this not work?

I considered and rejected that model for the following reason: there are
moments where both Alice and Bob can claim the BTC. If they both attempt to
do so, it also reveals both secrets, causing the LTC to also be claimable
by both parties. This chaotic scenario is a failure mode that did not seem
acceptable to me. The revoke transaction was specifically added to mitigate
that issue (invalidating any attempt of Bob to claim the coins and reveal
his secret). That said, it doesn't particularly seem in either party's
interest wait until a moment where two timelocks become valid, so maybe it
is not quite as bad as I thought. However, it still means that the
incompetence/malevolence of one party can lead to losses for both parties.
I have my doubts a gain in privacy in the uncooperative case is worth that
risk.

Of course it also reverts the protocol to 3 transactions, instead of 2, but
regardless, not having to watch the chain is probably more practical in
many cases. As an aside, if both chains support timelocks then we can
ensure that the more expensive chain only receives one transaction.

>if relative locktimes are used as often as absolute locktimes for
block-sniping-prevention and a decent Scriptless Script system, then all
protocol aborts should be doable with no information leaks

I see your point, interesting observation.

>A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on
the LTC side would not be in that HD, and if Alice wants to cold-store the
LTC, it should move the money as well into an HD pubkey.

Agreed, I had that listed as one of the disadvantages: "Access to money is
contingent on remembering secrets (backup complexity)"

Cheers,
Ruben


On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier 
wrote:

> A quick correction to my post:
>
>>
>> Here's where the truly novel part comes in. Ruben solves this by
>> extending the standard *TLC contract:
>> 1. Bob redeem with secret
>> 2. Alice refund after T1
>> 3. Bob redeem without secret after T2
>>
>> This is actually:
>
> 1. Bob redeem with redeem secret
> 2. Alice refund after T1 with refund secret
> 3. Bob redeem without secret after T2
>
> The fact that Alice reveals a secret when she refunds is crucial.
>
> LL
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread Richard Myers via bitcoin-dev
Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
concern as: A node without direct internet connectivity can not rely on an
opportunistically incentivized local network peer for blockchain
information because the off-grid node's direct LN peers could collude to
not forward the payment.

On Mon, May 11, 2020 at 7:44 AM ZmnSCPxj  wrote:

> > 2) a light client can query an ISP connected full node on the same
> unmetered local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or
> full blocks using a payment channel. Cost is reduced and privacy is
> enhanced for the light client by not using a centralized ISP. Bandwidth for
> running the full node can be amortized and subsidized by payments from
> light clients who they resell data to.
>
> A relatively pointless observation, but it seems to me that:
>
> * The light client is requesting for validation information, because...
> * ...its direct peers might be defrauding it, leading to...
> * ...the money it *thinks* it has in its channels being valueless.
>
> Thus, if the light client opportunistically pays for validation
> information (whether full blocks, headers, or filters), the direct peers it
> has could just as easily not forward any payments, thus preventing the
> light client from paying for the validation information.
>
> Indeed, if the direct peer *is* defrauding the light client, the direct
> peer has no real incentive to actually forward *any* payments --- to do so
> would be to reduce the possible earnings it gets from defrauding the light
> client.
> ("Simulating" the payments so that the light client will not suspect
> anything runs the risk that the light client will be able to forward all
> its money out of the channel, and the cheating peer is still potentially
> liable for any funds it originally had in the channel if it gets caught.)
>

One question I had is: how can a malicious direct payment peer "simulate" a
successful payment made by an off-grid victim peer to an information
source?  The censoring peer wouldn't be able to return the preimage for a
payment they failed to forward. Also, since the information provider and
off-grid node can presumably communicate via their local network
connection, it would be obvious if all of the victims LN peers were failing
to forward payments (whether maliciously or due to routing failures) to an
information provider they could otherwise communicate with.

Any LN payments not monitored by a watchtower that are received by the
eclipsed off-grid victim node would be at risk in this attack scenario.
Likewise any layer 1 payments they received should be buried under
sufficient valid block headers before being relied on.

I don't see how a LN node one-step removed from a direct internet
connection is at more risk than an internet connected node eclipsed by
their ISP, for example. In both cases, failure to get timely blockchain
info should trigger warnings to stop accepting payments.


> What would work would be to use a system similar to watchtowers, wherein
> the validation-information-provider is prepaid and issues tokens that can
> be redeemed later.
> But this is not suitable for opportunistic on-same-WiFi where, say, a
> laptop is running a validation-information-provider-for-payment program on
> the same WiFi as a light-client mobile phone, if we consider that the
> laptop and mobile may have never met before and may never meet again.
> It would work if the laptop altruistically serves the blocks, but not if
> it were for (on-Lightning) payment.
>

There's another problem if we can't rely on a recurring relationship with
an information provider besides not being able to prepay for validation
information doesn't make sense. We don't want an information provider to
collect payments for serving invalid information. Maybe for very small
payments this isn't a problem, but ideally validity could be coded into the
HTLC.

For example, an alternative HTLC construct that only paid for valid 81 B
headers that hash to 32 B values with a number of leading zeros committed
to by the HTLC. It would make more economic sense for an internet gateway
node to serve valid mined header to nodes on their local WiFi network than
to create bogus ones with the same (high) amount of work.


> So it seems to me that this kind of service is best ridden on top of
> watchtower service providers.
>

Public watchtowers or some sort of HTTP proxy data cache similar to a
watchtower makes the most sense to me because they would be expected to be
economically motivated and LN payment aware. Full nodes could potentially
be incentivized to exchange new data with other nodes in a tit-for-tat way,
but I don't expect them to be incentivized by light clients using LN
micropayments in a server-client arrangement.

Network agents that monetize full node information services beyond channel
monitoring would be more than just a "Watchtower" for light 

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
A quick correction to my post:

>
> Here's where the truly novel part comes in. Ruben solves this by extending
> the standard *TLC contract:
> 1. Bob redeem with secret
> 2. Alice refund after T1
> 3. Bob redeem without secret after T2
>
> This is actually:

1. Bob redeem with redeem secret
2. Alice refund after T1 with refund secret
3. Bob redeem without secret after T2

The fact that Alice reveals a secret when she refunds is crucial.

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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
Ruben,

In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done! I want to try and distil the core abstract
ideas here as they appear to me. From my view, the protocol is a
combination of two existing ideas and one new one:

1. In atomic swaps you can make the refund transaction on one chain
dependent on the refund on the other using secret revelation. Thus only one
chain needs to have a timelock and the other refund can be conditioned on a
secret that is revealed when that first refund goes through. (This idea is
in the monero atomic swap [1]).
2. Secret revelations can be used to give unconstrained spending power to
one party. With an adaptor signature, rather than reveal a decryption key
for another signature, you can just make the decryption key your signing
key in the multisig so when you reveal it with the adaptor signautre the
other party gains full knowledge of the private key for the output and can
spend it arbitrarily. (this is just folklore and already what happens in
HTLCs -- though it looks like lightning people are about to get rid of the
unconstrained spend I think).

The combination of these two ideas is novel in itself. The problem with
idea (2) is that your unconstrained spending power over an output doesn't
matter much if there is a pre-signed refund transaction spending from it --
you still have to spend it before the refund becomes valid. But if you
bring in idea (1)  this problem goes away!
However, you are left with a new problem: What if the party with the
timelock never refunds? Then the funds are locked forever.

Here's where the truly novel part comes in. Ruben solves this by extending
the standard *TLC contract:
1. Bob redeem with secret
2. Alice refund after T1
3. Bob redeem without secret after T2

We might call this a "Forced Refund *TLC". Alice must claim the refund or
lose her money. This forces the refund secret revelation through
punishment. If Alice refuses to refund Bob gets the asset he wanted anyway!

The resulting protocol you get from applying these ideas is three
transactions. At the end, one party has their funds in a non HD key output
but if they want that they can just transfer it to an HD output in which
case you get four transactions again. Thus I consider this to be a strict
improvement over the four transaction protocol. Furthermore, one of the
chains does not need a timelock. This is remarkable as the four transaction
atomic swap is one of the most basic and most studied protocols. I
considered it to be kind of "perfect" in a way. It just goes to show that
this field is still very new and there are still things to discover in what
we think is the most well trodden ground.

I don't want to ignore that Ruben presents us with a two transaction
protocol. He made a nice video explaining it here:
https://www.youtube.com/watch?v=TlCxpdNScCA. It is harder to see the
elegance of the idea in the two tx protocol because it involves revocation
and relative timelocks etc. Actually, it is straightforward to naively
achieve a two tx atomic swap with payment channels:
1. Alice and Bob set up payment channels to each other on different chains
2. They atomic swap the balances of the channels off-chain using HTLCs
using the standard protocol.
3. Since one party exclusively owns the funds in each channel the party
with no funds simply reveals their key in the funding OP_CHECKMULTISIG to
the other
4. Both parties now watch the chain to see if the other tries to post a
commitment transactions.

The advantages that Ruben's two tx protocol has over this is that timelocks
and monitoring is only needed on one of the chains. This is nothing to
scoff at but for me the three tx protocol is the most elegant expression of
the idea and the two tx protocol is a more optimised version that might
make sense in some circumstances.

[1] https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md

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