00:30:48 <kayabaNerve> So, while I find the paper extremely irritating in presentation, I will say as far as I can tell, this is symmetric.
00:31:27 <kayabaNerve> As in, this would enable swaps between any two elliptic cryptocurrencies.
00:31:57 <kayabaNerve> BTC/BCH/ADA/ETH/NANO/XMR... any of them. The existing atomic swap solution only does XMR against BTC/ETH.
00:32:36 <kayabaNerve> Whereas this allows both coins to be naive and use standard transactions, meaning it works for any coin.
00:33:01 <kayabaNerve> *BCH has timelock functionality. The existing atomic swap setup requires chaining TXs. BCH doesn't support that due to mutability problems.
10:21:17 <h4sh3d[m]> The PC part is Interesting. I didn't look carefully the VTLRS part (I assumed it works ;p) but PC is designed as Spilman-style, with T not inforced by the blockchain itself but with VTLRS.
10:21:40 <h4sh3d[m]> I've drafter some though about PC here: https://gitlab.com/TrueLevel/payment-channels/channel-analysis/-/blob/master/channel-analysis.pdf
10:22:55 <h4sh3d[m]> (this has never been posted nor reviewed, take it as a draft of my thoughts on PC, mostly based on Btc ones)
10:23:25 <h4sh3d[m]> But what you describe in your paper comes to the same conclusion IMO
10:24:36 <h4sh3d[m]> As pointed by kayabaNerve, for the atomic swap, it is not as generic as claimed because of the unbroadcasted chain of transactions problem.
10:25:52 <h4sh3d[m]> You have to open a PC on both chains (or something similar), and you can't in e.g. BCH
10:26:20 <h4sh3d[m]> I'm not that familiar with Anonymous Multi-Hop Locks for BlockchainScalability and Interoperability, so correct me if I'm wrong
10:41:02 <h4sh3d[m]> The client/payer is the one who try to resolve the puzzle to get the the refund tx, does the computation be paused and resumed from saved state? Or if he loses the work done on the puzzle he must restart from the beginning?
11:37:21 <h4sh3d[m]> In my current understanding, in Monero, to spend an output you need a set of keys (the ring) which is contained in the `key_offsets` field in the transaction, which is signed. Those offsets are relative to each other and are computed based on the blockchain state, which means that you need all the outputs you're referring to in the ring to be mined. How do you achieve to construct and sign the refund
11:37:21 <h4sh3d[m]> transaction before mining the fund transaction?
11:41:41 <aravind2212[m]> <h4sh3d[m] "The client/payer is the one who "> I think you can pause and restart if you want..it is just sequential squaring. You can outsource this computation too.
11:42:56 <aravind2212[m]> <h4sh3d[m] "You have to open a PC on both ch"> Why is this a problem in BCH?
11:44:10 <zkao> there's no segwit, thus u cant safely chain transactions offchain, because txid maleability problem
11:45:23 <aravind2212[m]> <zkao[m] "there's no segwit, thus u cant s"> I see. We will make sure to clarify this in the paper. But seems not a conceptual problem right?
11:47:40 <aravind2212[m]> <h4sh3d[m] "In my current understanding, in "> I am not familiar with the concrete functioning of transactions depending on the state of the blockchain. What if your transaction is delayed in the network and it falls out of state with the blockchain? Can you estimate this blockchain state or is it unpredictable?
11:48:37 <zkao> the relative key_offset problem h4sh3d mentions for monero is similar in nature to the BCH problem -- u just know for sure the tx identifier after tx is mined
11:51:25 <aravind2212[m]> <zkao[m] "the relative key_offset problem "> is this crucial for security or?
11:51:50 <zkao> yes, first u need a signed refund tx
11:52:24 <zkao> before locking the funds, right?
11:53:20 <aravind2212[m]> yes. that is crucial for our PC protocol. I asked if this relative key_offset is crucial for the security of current monero
12:22:19 <aravind2212[m]> The VTLRS is crucial when you want to do atomic swaps in a scriptless script fashion. if you only want PC there is a simpler variant that I can tell you about that bypasses the relative key_offset problem you mention.
13:16:16 <UkoeHB__> relative key offsets are not essential, they can be replaced with ID lookups at some cost
13:17:41 <UkoeHB__> however there is the Guess Newest heuristic for tx chaining, which just means 'guess the newest output in a ring sig is real signer'; tx chaining means all your ring members must be old
13:29:24 <aravind2212[m]> <UkoeHB__ "relative key offsets are not ess"> I did not quick catch all the details..but if it helps set a refund transaction ahead of time, thats good. PayMo should go through.. correct me if i am wrong though
13:55:49 <UkoeHB__> well I doubt they will be replaced any time soon
21:52:29 <kayabaNerve> h4sh3d[m]: You're right, sorry. You do need a single unbroadcasted refund TX in advance.
22:12:39 <aravind2212[m]> <aravind2212[m] "The VTLRS is crucial when you wa"> As i mentioned here, if you are only interested in PC you can get around this 'problem', with a simpler variant of our scheme. For atomic swap you seem to require an unbroadcasted refund transaction
22:27:07 <zkao> please share the simplified variant of payment channel that bypasses the problem -- we have an understanding on how to build atomic swaps witout protocol changes, but not payment channels