Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
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
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] SAS: Succinct Atomic Swap
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
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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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
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
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
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] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
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
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
