-
kayabaNerve
So, while I find the paper extremely irritating in presentation, I will say as far as I can tell, this is symmetric.
-
kayabaNerve
As in, this would enable swaps between any two elliptic cryptocurrencies.
-
kayabaNerve
BTC/BCH/ADA/ETH/NANO/XMR... any of them. The existing atomic swap solution only does XMR against BTC/ETH.
-
kayabaNerve
Whereas this allows both coins to be naive and use standard transactions, meaning it works for any coin.
-
kayabaNerve
*BCH has timelock functionality. The existing atomic swap setup requires chaining TXs. BCH doesn't support that due to mutability problems.
-
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.
-
h4sh3d[m]
-
h4sh3d[m]
(this has never been posted nor reviewed, take it as a draft of my thoughts on PC, mostly based on Btc ones)
-
h4sh3d[m]
But what you describe in your paper comes to the same conclusion IMO
-
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.
-
h4sh3d[m]
You have to open a PC on both chains (or something similar), and you can't in e.g. BCH
-
h4sh3d[m]
I'm not that familiar with Anonymous Multi-Hop Locks for BlockchainScalability and Interoperability, so correct me if I'm wrong
-
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?
-
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
-
h4sh3d[m]
transaction before mining the fund transaction?
-
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.
-
aravind2212[m]
<h4sh3d[m] "You have to open a PC on both ch"> Why is this a problem in BCH?
-
zkao
there's no segwit, thus u cant safely chain transactions offchain, because txid maleability problem
-
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?
-
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?
-
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
-
aravind2212[m]
<zkao[m] "the relative key_offset problem "> is this crucial for security or?
-
zkao
yes, first u need a signed refund tx
-
zkao
before locking the funds, right?
-
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
-
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.
-
UkoeHB__
relative key offsets are not essential, they can be replaced with ID lookups at some cost
-
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
-
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
-
UkoeHB__
well I doubt they will be replaced any time soon
-
kayabaNerve
h4sh3d[m]: You're right, sorry. You do need a single unbroadcasted refund TX in advance.
-
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
-
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