{"type":"rich","version":"1.0","author_name":"npub1pzahhguklemv3yzw3rszdkgy56999h235a9rfx5naxp63dwd6pns7x2ld8","author_url":"https://nostr.ae/npub1pzahhguklemv3yzw3rszdkgy56999h235a9rfx5naxp63dwd6pns7x2ld8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-04-23\n📝 Original message:Good morning  ZmnSCPxj,\n\nThank you for your excellent feedback!\n\nIndeed, with a little protocol-level sugar so that the coins being swapped\nget paid out of different pubkeys.\nI read your article. Excellent idea on the randomized locktimes! I've still\nto read the details of what S6 amounts to but I'm excited to.\n\nWith regards to trying to tackle the problem of value-based correlations,\nwouldn't it be possible to try to model the solution after the\nequal-sum-subset problem (np complete problem)(\nhttps://www.cs.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf\n)?\nThat is, a pair of individuals with a set of UTXOs that both add up to\nsimilar if not equal value perform a swap of similar-(total)value sets. In\nthis way the values of the UTXOs can be broken up essentially at random\n(following some nominal distribution so that it doesn't stand out; e.g.\nhttps://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction\nand decorrelated by using different keys + randomized locktimes.\n\n\nRegards,\nGermán\n\nOn Thu, Apr 23, 2020 at 11:56 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Germán,\n\u003e\n\u003e It looks to me like this is CoinSwap with Schnorr Scriptless Scripts.\n\u003e\n\u003e * https://joinmarket.me/blog/blog/coinswaps/\n\u003e *\n\u003e https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/\n\u003e\n\u003e I also recently put up an article on extending such a protocol across 3 or\n\u003e more participants:\n\u003e\n\u003e * https://zmnscpxj.github.io/bitcoin/multiswap.html\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e \u003e ## Objective\n\u003e \u003e * Make atomic swaps within the same chain possible in a traceless way\n\u003e \u003e * Achieving traceless same-chain atomic-swaps effectively turns an\n\u003e entire chain into a  (P2PKH) mixer by default\n\u003e \u003e\n\u003e \u003e ## Proposed solution\n\u003e \u003e Similar to the way that atomic swaps would work with schnorr signatures\n\u003e (i.e. leveraging adaptor signatures), the proposed solution is to use - in\n\u003e place of the secret 't' - a suitably chosen schnorr signature. The end\n\u003e result being that when one counterparty claims their side of the funds, the\n\u003e party can obtain the signature they're missing to claim the funds in the\n\u003e (schnorr) multisig that pays them.\n\u003e \u003e On-chain, this would appear like two independent transactions, even\n\u003e though effectively the two parties have “exchanged” the history attached to\n\u003e the UTXOs. Unlike a mixing service, in which all of the histories get\n\u003e merged, with this protocol histories can be pairwise swapped without\n\u003e anybody’s knowledge.\n\u003e \u003e\n\u003e \u003e ## Protocol description\n\u003e \u003e * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2\n\u003e (controlled by Bob) wish to swap them.\n\u003e \u003e * Alice provides Bob with a single public key P_A\n\u003e \u003e * Bob provides Alice two pubkeys P_B1, P_B2.\n\u003e \u003e * Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1)\n\u003e [where the UTXO1 funds will be sent to eventually] and Addr2  =\n\u003e Hash(P_A+P_B2) [where the UTXO2 funds will be sent to eventually]\n\u003e \u003e * Bob and Alice exchange time-locked refund transactions for the funding\n\u003e transactions sending the funds to Addr1 and Addr2.\n\u003e \u003e * Bob and Alice submit the funding transactions (Alice pays to Addr1\n\u003e from UTXO1; Bob pays to Addr2 from UTXO2)\n\u003e \u003e * Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2\n\u003e | m')*x_a\n\u003e \u003e * Bob verifies the adaptor signature Alice sent contains a valid\n\u003e signature for spending from Addr1 AND another valid signature for spending\n\u003e from Addr2. Both signatures from Alice. Bob cannot separate out the two\n\u003e signatures and hence cannot claim any of the funds, provided H( r1 | m) !=\n\u003e H( r2 | m') in the signature commitment.\n\u003e \u003e * Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2\n\u003e \u003e * Alice can now add her signature to Bob's and get: r2 + H( r2| m'\n\u003e )*(x_b2 + x_a) which is a valid signature to spend the funding transaction\n\u003e sent to Addr2.\n\u003e \u003e * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that\n\u003e signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2\n\u003e | m' )*x_b2) = H( r2 | m ')*x_a\n\u003e \u003e * Bob takes the original adaptor signature and subtracts the known\n\u003e quantity r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m\n\u003e )*x_a\n\u003e \u003e * Bob can now add to that valid signature, his own signature and\n\u003e retrieve the funds.\n\u003e \u003e ## Notes\n\u003e \u003e * It is possible for the counterparty to store copies of the signatures\n\u003e as proof that such a join has taken place. But plausible deniability is\n\u003e available upon discarding signatures since the joint private keys (x_a +\n\u003e x_b*) are unavailable.\n\u003e \u003e\n\u003e \u003e I'm interested in hearing feedback on this idea if possible, and deemed\n\u003e interesting enough.\n\u003e \u003e\n\u003e \u003e Best regards,\n\u003e \u003e --\n\u003e \u003e Germán\n\u003e \u003e Mathematician\n\u003e\n\u003e\n\u003e\n\n-- \nGermán\nMathematician\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200423/dc5c6c2a/attachment-0001.html\u003e"}