📅 Original date posted:2018-01-22
📝 Original message:This sounds like a useful idea for improving the privacy of coinswap.
Traditionally coinswap mixing had an anonymity set related to the number
of multisig transactions being used on the blockchain. With the new tech
of Schnorr, MAST and now this Taproot, with sufficient adoption
coinswap's anonymity set could be much higher, potentially including
almost every other on-chain transaction.
[1] https://bitcointalk.org/index.php?topic=321228.0
[2] https://github.com/AdamISZ/CoinSwapCS
On 23/01/18 00:30, Gregory Maxwell via bitcoin-dev wrote:
> Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties. Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that _any_ contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really. The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it. I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off. The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B. (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S = "<timeout> OP_CSV OP_DROP B OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named key, or a spending transaction could provide a script along with
> a signature of that script by the named key, delegating control to the
> signed script. Before paying into that escrow Alice/Bob would
> construct this signature. This idea is equally efficient in the common
> case, but larger and slower to verify in the alternative spend case.
> Setting up the signature requires additional interaction between
> participants and the resulting signature must be durably stored and
> couldn't just be recomputed using single-party information.
>
> I believe this construction will allow the largest possible anonymity
> set for fixed party smart contracts by making them look like the
> simplest possible payments. It accomplishes this without any overhead
> in the common case, invoking any sketchy or impractical techniques,
> requiring extra rounds of interaction between contract participants,
> and without requiring the durable storage of other data.
>
>
> [1] https://eprint.iacr.org/2018/068
> [2] https://blockstream.com/sidechains.pdf Appendix A
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Chris Belcher [ARCHIVE] /
npub1ek…lnm2u
2023-06-07 18:10:05
in reply to nevent1q…u8uu
Author Public Key
npub1ekvnqhww3aagwuj9t55dgj5y29u8cxdjllfv3vgppt8vc0zljhrs6lnm2uPublished at
2023-06-07 18:10:05Event JSON
{
"id": "6acdf2921f40c255a649934f7bc9e901a6b963834fec003696b2871251e0a311",
"pubkey": "cd99305dce8f7a8772455d28d44a8451787c19b2ffd2c8b1010acecc3c5f95c7",
"created_at": 1686161405,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"4d8593b374d2c5079277d65a5366ecbf8c67565bd12c2ffdb7321b968e95f493",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-01-22\n📝 Original message:This sounds like a useful idea for improving the privacy of coinswap.\nTraditionally coinswap mixing had an anonymity set related to the number\nof multisig transactions being used on the blockchain. With the new tech\nof Schnorr, MAST and now this Taproot, with sufficient adoption\ncoinswap's anonymity set could be much higher, potentially including\nalmost every other on-chain transaction.\n\n[1] https://bitcointalk.org/index.php?topic=321228.0\n[2] https://github.com/AdamISZ/CoinSwapCS\n\nOn 23/01/18 00:30, Gregory Maxwell via bitcoin-dev wrote:\n\u003e Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main\n\u003e areas: efficiency and privacy. Efficiency because unexecuted forks of\n\u003e a script can avoid ever hitting the chain, and privacy because hiding\n\u003e unexecuted code leaves scripts indistinguishable to the extent that\n\u003e their only differences are in the unexecuted parts.\n\u003e \n\u003e As Mark Friedenbach and others have pointed out before it is almost\n\u003e always the case that interesting scripts have a logical top level\n\u003e branch which allows satisfaction of the contract with nothing other\n\u003e than a signature by all parties. Other branches would only be used\n\u003e where some participant is failing to cooperate. More strongly stated,\n\u003e I believe that _any_ contract with a fixed finite participant set\n\u003e upfront can be and should be represented as an OR between an N-of-N\n\u003e and whatever more complex contract you might want to represent.\n\u003e \n\u003e One point that comes up while talking about merkelized scripts is can\n\u003e we go about making fancier contract use cases as indistinguishable as\n\u003e possible from the most common and boring payments. Otherwise, if the\n\u003e anonymity set of fancy usage is only other fancy usage it may not be\n\u003e very large in practice. One suggestion has been that ordinary\n\u003e checksig-only scripts should include a dummy branch for the rest of\n\u003e the tree (e.g. a random value hash), making it look like there are\n\u003e potentially alternative rules when there aren't really. The negative\n\u003e side of this is an additional 32-byte overhead for the overwhelmingly\n\u003e common case which doesn't need it. I think the privacy gains are\n\u003e worth doing such a thing, but different people reason differently\n\u003e about these trade-offs.\n\u003e \n\u003e It turns out, however, that there is no need to make a trade-off. The\n\u003e special case of a top level \"threshold-signature OR\n\u003e arbitrary-conditions\" can be made indistinguishable from a normal\n\u003e one-party signature, with no overhead at all, with a special\n\u003e delegating CHECKSIG which I call Taproot.\n\u003e \n\u003e Let's say we want to create a coin that can be redeemed by either\n\u003e Alice \u0026\u0026 Bob or by CSV-timelock \u0026\u0026 Bob.\n\u003e \n\u003e Alice has public A, Bob has pubkey B.\n\u003e \n\u003e We compute the 2-of-2 aggregate key C = A + B. (Simplified; to\n\u003e protect against rogue key attacks you may want to use the MuSig key\n\u003e aggregation function [1])\n\u003e \n\u003e We form our timelock script S = \"\u003ctimeout\u003e OP_CSV OP_DROP B OP_CHECKSIGVERIFY\"\n\u003e \n\u003e Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.\n\u003e \n\u003e (This is the attack hardened pay-to-contract construction described in [2])\n\u003e \n\u003e Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].\n\u003e \n\u003e Now Alice and Bob-- assuming they are both online and agree about the\n\u003e resolution of their contract-- can jointly form a 2 of 2 signature for\n\u003e P, and spend as if it were a payment to a single party (one of them\n\u003e just needs to add H(C||S) to their private key).\n\u003e \n\u003e Alternatively, the Taproot consensus rules would allow this script to\n\u003e be satisfied by someone who provides the network with C (the original\n\u003e combined pubkey), S, and does whatever S requires-- e.g. passes the\n\u003e CSV check and provides Bob's signature. With this information the\n\u003e network can verify that C + H(C||S) == P.\n\u003e \n\u003e So in the all-sign case there is zero overhead; and no one can tell\n\u003e that the contract alternative exists. In the alternative redemption\n\u003e branch the only overhead is revealing the original combined pubkey\n\u003e and, of course, the existence of the contract is made public.\n\u003e \n\u003e This composes just fine with whatever other merkelized script system\n\u003e we might care to use, as the S can be whatever kind of data we want,\n\u003e including the root of some tree.\n\u003e \n\u003e My example shows 2-of-2 but it works the same for any number of\n\u003e participants (and with setup interaction any threshold of\n\u003e participants, so long as you don't mind an inability to tell which\n\u003e members signed off).\n\u003e \n\u003e The verification computational complexity of signature path is\n\u003e obviously the same as any other plain signature (since its\n\u003e indistinguishable). Verification of the branch redemption requires a\n\u003e hash and a multiplication with a constant point which is strictly more\n\u003e efficient than a signature verification and could be efficiently fused\n\u003e into batch signature validation.\n\u003e \n\u003e The nearest competitor to this idea that I can come up with would\n\u003e supporting a simple delegation where the output can be spent by the\n\u003e named key, or a spending transaction could provide a script along with\n\u003e a signature of that script by the named key, delegating control to the\n\u003e signed script. Before paying into that escrow Alice/Bob would\n\u003e construct this signature. This idea is equally efficient in the common\n\u003e case, but larger and slower to verify in the alternative spend case.\n\u003e Setting up the signature requires additional interaction between\n\u003e participants and the resulting signature must be durably stored and\n\u003e couldn't just be recomputed using single-party information.\n\u003e \n\u003e I believe this construction will allow the largest possible anonymity\n\u003e set for fixed party smart contracts by making them look like the\n\u003e simplest possible payments. It accomplishes this without any overhead\n\u003e in the common case, invoking any sketchy or impractical techniques,\n\u003e requiring extra rounds of interaction between contract participants,\n\u003e and without requiring the durable storage of other data.\n\u003e \n\u003e \n\u003e [1] https://eprint.iacr.org/2018/068\n\u003e [2] https://blockstream.com/sidechains.pdf Appendix A\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "fa2f1a0f2b2f3cbd1de4d9ca8cf60ccafc0d50c18ee5b6926c9c18739eb9e05806a73b1123dbbc1adbb88ea6ca1b9f2cf4cc330984254830e8ca87731e72499e"
}