• Breaking News

    Tuesday, August 18, 2020

    Home Unlabelled Bitcoin Taproot, CoinJoins, and Cross-Input Signature Aggregation

    Bitcoin Taproot, CoinJoins, and Cross-Input Signature Aggregation

    August 18, 2020

    Bitcoin Taproot, CoinJoins, and Cross-Input Signature Aggregation

    Taproot, CoinJoins, and Cross-Input Signature Aggregation

    Posted: 17 Aug 2020 04:51 AM PDT

    It is a very common misconception that the upcoming Taproot upgrade helps CoinJoin.

    TLDR: The upcoming Taproot upgrade does not help equal-valued CoinJoin at all, though it potentially increases the privacy of other protocols, such as the Lightning Network, and escrow contract schemes.

    If you want to learn more, read on!

    Equal-valued CoinJoins

    Let's start with equal-valued CoinJoins, the type JoinMarket and Wasabi use. What happens is that some number of participants agree on some common value all of them use. With JoinMarket the taker defines this value and pays the makers to agree to it, with Wasabi the server defines a value approximately 0.1 BTC.

    Then, each participant provides inputs that they unilaterally control, totaling equal or greater than the common value. Typically since each input is unilaterally controlled, each input just requires a singlesig. Each participant also provides up to two addresses they control: one of these will be paid with the common value, while the other will be used for any extra value in the inputs they provided (i.e. the change output).

    The participants then make a single transaction that spends all the provided inputs and pays out to the appropriate outputs. The inputs and outputs are shuffled in some secure manner. Then the unsigned transaction is distributed back to all participants.

    Finally, each participant checks that the transaction spends the inputs it provided (and more importantly does not spend any other coins it might own that it did not provide for this CoinJoin!) and that the transaction pays out to the appropriate address(es) it controls. Once they have validated the transaction, they ratify it by signing for each of the inputs it provided.

    Once every participant has provided signatures for all inputs it registered, the transaction is now completely signed and the CoinJoin transaction is now validly confirmable.

    CoinJoin is a very simple and direct privacy boost, it requires no SCRIPTs, needs only singlesig, etc.

    Privacy

    Let's say we have two participants who have agreed on a common amount of 0.1 BTC. One provides a 0.105 coin as input, the other provides a 0.114 coin as input. This results in a CoinJoin with a 0.105 coin and a 0.114 coin as input, and outputs with 0.1, 0.005, 0.014, and 0.1 BTC.

    Now obviously the 0.005 output came from the 0.105 input, and the 0.014 output came from the 0.114 input.

    But the two 0.1 BTC outputs cannot be correlated with either input! There is no correlating information, since either output could have come from either input. That is how common CoinJoin implementations like Wasabi and JoinMarket gain privacy.

    Banning CoinJoins

    Unfortunately, large-scale CoinJoins like that made by Wasabi and JoinMarket are very obvious.

    All you have to do is look for a transactions where, say, more than 3 outputs are the same equal value, and the number of inputs is equal or larger than the number of equal-valued outputs. Thus, it is trivial to identify equal-valued CoinJoins made by Wasabi and JoinMarket. You can even trivially differentiate them: Wasabi equal-valued CoinJoins are going to have a hundred or more inputs, with outputs that are in units of approximately 0.1 BTC, while JoinMarket CoinJoins have equal-valued outputs of less than a dozen (between 4 to 6 usually) and with the common value varying wildly from as low as 0.001 BTC to as high as a dozen BTC or more.

    This has led to a number of anti-privacy exchanges to refuse to credit custodially-held accounts if the incoming deposit is within a few hops of an equal-valued CoinJoin, usually citing concerns about regulations. Crucially, the exchange continues to hold private keys for those "banned" deposits, and can still spend them, thus this is effectively a theft. If your exchange does this to you, you should report that exchange as stealing money from its customers. Not your keys not your coins.

    Thus, CoinJoins represent a privacy tradeoff:

    • It's very hard for everyone else to determine which output belongs to which input.
    • It's obvious to everyone else that the output was involved in a mixing operation.

    Taproot

    Let's now briefly discuss that nice new shiny thing called Taproot.

    Taproot includes two components:

    • The use of Schnorr-based signature scheme, with multisignature support. Spending from a Schnorr pubkey is called a "keypath spend".
    • The ability to secretly commit to a set of scripts, one of which can be revealed later and its inputs provided correctly in order to spend the coin. Spending via a hidden script is called a "scriptpath spend".

    This has some nice properties:

    • Direct multisignature support means all multisignature uses look the same. In current Bitcoin, a 2-of-2 "multisignature" is really a script which demands that two signatures be provided, from 2 different pre-specified public keys. To a cryptographer, the strict definition of multisignature is that this is a single signature that is cooperatively created by multiple parties.
      • A typical minimal "multisig" setup would be a 2-of-3, because that lets you lose one signing device while still being able to keep access to your money, and still providing an increase in security relative to a singlesig, since a 2-of-3 requires that potential thieves abscond with at least two signing devices. In current Bitcoin, a 2-of-3 is a SCRIPT containing 3 public keys, requiring that two signatures from those three public keys be provided.
      • But a Lightning Network channel has exactly two participants. Thus, it uses a 2-of-2, and is a SCRIPT containing 2 public keys, requiring that two signatures from those public keys be provided. If you look for 2-of-2 spends on the blockchain after Lightning became cool, the chances are very good that a random 2-of-2 spend is a Lightning Network channel being closed, because there are hardly ever any other uses of 2-of-2.
      • Just from there, you can easily differentiate the most common HODLer multisig of 2-of-3 (SCRIPT contains 3 pubkeys) from the Lightning channel 2-of-2 (SCRIPT contains 2 pubkeys).
      • Fortunately, with Taproot, 2-of-3 and 2-of-2 (and any arbitrary k-of-n) can look exactly the same, because Schnorr allows for the cryptographer's strict definition of "multisignature": a single signature cooperatively created by multiple parties.
    • Complex SCRIPTs, like HTLCs, can be hidden in a Taproot output.
      • For example, the output can have a keyspend branch that is a n-of-n of all participants, with hidden SCRIPTs that encode the conditions under which the output can be spent
      • The hidden SCRIPTs ensure that the protocol is followed. If one of the participants drops from the protocol, the rest can reveal the hidden SCRIPTs and follow their conditions.
      • If everyone follows the protocol correctly, and agrees to the result, they can all cooperatively sign with the keyspend n-of-n. They can just all agree on what the result of the SCRIPTs would be, and sign a transaction that performs that, without revealing any SCRIPTs. Since all of them agreed on the result, nobody should complain (if one of them believes the result is not correct, they can just refuse to sign and force everyone else to publish the SCRIPTs onchain).
      • If everyone agrees, they get privacy: none of the SCRIPTs they were following ever get published onchain, and it looks like every other multisignature spend.

    Taproot DOES NOT HELP CoinJoin

    So let's review!

    CoinJoin:

    • CoinJoin inputs are singlesig
    • There are no SCRIPTs involved in CoinJoin.

    Taproot:

    • Improves multisig privacy.
    • Improves SCRIPT privacy.

    There is absolutely no overlap. Taproot helps things that CoinJoin does not use. CoinJoin uses things that Taproot does not improve.

    B-but They Said!!

    A lot of early reporting on Taproot claimed that Taproot benefits CoinJoin.

    What they are confusing is that earlier drafts of Taproot included a feature called cross-input signature aggregation.

    In current Bitcoin, every input, to be spent, has to be signed individually. With cross-input signature aggregation, all inputs that support this feature are signed with a single signature that covers all those inputs. So for example if you would spend two inputs, current Bitcoin requires a signature for each input, but with cross-input signature aggregation you can sign both of them with a single signature. This works even if the inputs have different public keys: two inputs with cross-input signature aggregation effectively define a 2-of-2 public key, and you can only sign for that input if you know the private keys for both inputs, or if you are cooperatively signing with somebody who knows the private key of the other input.

    This helps CoinJoin costs. Since CoinJoins will have lots of inputs (each participant will provide at least one, and probably will provide more, and larger participant sets are better for more privacy in CoinJoin), if all of them enabled cross-input signature aggregation, such large CoinJoins can have only a single signature.

    This complicates the signing process for CoinJoins (the signers now have to sign cooperatively) but it can be well worth it for the reduced signature size and onchain cost.

    But note that the while cross-input signature aggregation improves the cost of CoinJoins, it does not improve the privacy! Equal-valued CoinJoins are still obvious and still readily bannable by privacy-hating exchanges. It does not improve the privacy of CoinJoin. Instead, see https://old.reddit.com/r/Bitcoin/comments/gqb3ur/design_for_a_coinswap_implementation_for/

    Why isn't cross-input signature aggregation in?

    There's some fairly complex technical reasons why cross-input signature aggregation isn't in right now in the current Taproot proposal.

    The primary reason was to reduce the technical complexity of Taproot, in the hope that it would be easier to convince users to activate (while support for Taproot is quite high, developers have become wary of being hopeful that new proposals will ever activate, given the previous difficulties with SegWit).

    The main technical complexity here is that it interacts with future ways to extend Bitcoin.

    The rest of this writeup assumes you already know about how Bitcoin SCRIPT works. If you don't understand how Bitcoin SCRIPT works at the low-level, then the TLDR is that cross-input signature aggregation complicates how to extend Bitcoin in the future, so it was deferred to let the develoeprs think more about it.

    (this is how I understand it; perhaps /u/pwuille or /u/ajtowns can give a better summary.)

    In detail, Taproot also introduces OP_SUCCESS opcodes. If you know about the OP_NOP opcodes already defined in current Bitcoin, well, OP_SUCCESS is basically "OP_NOP done right".

    Now, OP_NOP is a do-nothing operation. It can be replaced in future versions of Bitcoin by having that operation check some condition, and then fail if the condition is not satisfied. For example, both OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY were previously OP_NOP opcodes. Older nodes will see an OP_CHECKLOCKTIMEVERIFY and think it does nothing, but newer nodes will check if the nLockTime field has a correct specified value, and fail if the condition is not satisfied. Since most of the nodes on the network are using much newer versions of the node software, older nodes are protected from miners who try to misspend any OP_CHECKLOCKTIMEVERIFY/OP_CHECKSEQUENCEVERIFY, and those older nodes will still remain capable of synching with the rest of the network: a dedication to strict backward-compatibility necessary for a consensus system.

    Softforks basically mean that a script that passes in the latest version must also be passing in all older versions. A script cannot be passing in newer versions but failing in older versions, because that would kick older nodes off the network (i.e. it would be a hardfork).

    But OP_NOP is a very restricted way of adding opcodes. Opcodes that replace OP_NOP can only do one thing: check if some condition is true. They can't push new data on the stack, they can't pop items off the stack. For example, suppose instead of OP_CHECKLOCKTIMEVERIFY, we had added a OP_GETBLOCKHEIGHT opcode. This opcode would push the height of the blockchain on the stack. If this command replaced an older OP_NOP opcode, then a script like OP_GETBLOCKHEIGHT 650000 OP_EQUAL might pass in some future Bitcoin version, but older versions would see OP_NOP 650000 OP_EQUAL, which would fail because OP_EQUAL expects two items on the stack. So older versions will fail a SCRIPT that newer versions will pass, which is a hardfork and thus a backwards incompatibility.

    OP_SUCCESS is different. Instead, old nodes, when parsing the SCRIPT, will see OP_SUCCESS, and, without executing the body, will consider the SCRIPT as passing. So, the OP_GETBLOCKHEIGHT 650000 OP_EQUAL example will now work: a future version of Bitcoin might pass it, and existing nodes that don't understand OP_GETBLOCKHEIGHT will se OP_SUCCESS 650000 OP_EQUAL, and will not execute the SCRIPT at all, instead passing it immediately. So a SCRIPT that might pass in newer versions will pass for older versions, which keeps the back-compatibility consensus that a softfork needs.

    So how does OP_SUCCESS make things difficult for cross-input signatur aggregation? Well, one of the ways to ask for a signature to be verified is via the opcodes OP_CHECKSIGVERIFY. With cross-input signature aggregation, if a public key indicates it can be used for cross-input signature aggregation, instead of OP_CHECKSIGVERIFY actually requiring the signature on the stack, the stack will contain a dummy 0 value for the signature, and the public key is instead added to a "sum" public key (i.e. an n-of-n that is dynamically extended by one more pubkey for each OP_CHECKSIGVERIFY operation that executes) for the single signature that is verified later by the cross-input signature aggregation validation algorithm00.

    The important part here is that the OP_CHECKSIGVERIFY has to execute, in order to add its public key to the set of public keys to be checked in the single signature.

    But remember that an OP_SUCCESS prevents execution! As soon as the SCRIPT is parsed, if any opcode is OP_SUCCESS, that is considered as passing, without actually executing the SCRIPT, because the OP_SUCCESS could mean something completely different in newer versions and current versions should assume nothing about what it means. If the SCRIPT contains some OP_CHECKSIGVERIFY command in addition to an OP_SUCCESS, that command is not executed by current versions, and thus they cannot add any public keys given by OP_CHECKSIGVERIFY. Future versions also have to accept that: if they parsed an OP_SUCCESS command that has a new meaning in the future, and then execute an OP_CHECKSIGVERIFY in that SCRIPT, they cannot add the public key into the same "sum" public key that older nodes use, because older nodes cannot see them. This means that you might need more than one signature in the future, in the presence of an opcode that replaces some OP_SUCCESS.

    Thus, because of the complexity of making cross-input signature aggregation work compatibly with future extensions to the protocol, cross-input signature aggregation was deferred.

    submitted by /u/almkglor
    [link] [comments]

    OK Nobody touch anything!!

    Posted: 17 Aug 2020 12:11 PM PDT

    Bitcoin now worth more than all of the New Zealand Dollars in existance. #34 largest currency in the world.

    Posted: 17 Aug 2020 01:33 PM PDT

    https://fiatmarketcap.com/

    #34 largest currency in the world.

    submitted by /u/atrueretard
    [link] [comments]

    When this happens; don't say I didn't tell you to buy ฿itcoin

    Posted: 17 Aug 2020 09:25 PM PDT

    Gold: can't validate scarcity, can't validate authenticity, can't transport, can't divide, can't hide. Bitcoin shines at everything gold ever wanted to do.

    Posted: 17 Aug 2020 07:04 AM PDT

    Can you believe it? It's been 12 years to the day since the bitcoin.org domain was registered!

    Posted: 18 Aug 2020 01:15 AM PDT

    I don't care if Bitcoin goes to zero, it's our best shot at free people's money

    Posted: 17 Aug 2020 09:42 AM PDT

    If bitcoin was impeded, there's no freedom anyways. Gold won't really help you in that case either.

    But that's just my two satoshis.

    submitted by /u/nick-bravo
    [link] [comments]

    Those Who Say Bitcoin Can’t Reach $1 Million Are the Same People Who Said Bitcoin Can’t Reach $10K

    Posted: 17 Aug 2020 11:12 AM PDT

    The market cap for bitcoin just surpassed Bank of America!

    Posted: 17 Aug 2020 10:19 AM PDT

    Turkey Hit By Bank Runs, Currency Panic As Locals Sell Their Cars And Houses To Buy Gold While Lira Implodes

    Posted: 17 Aug 2020 07:24 PM PDT

    The revolution is just starting.

    Posted: 17 Aug 2020 02:15 PM PDT

    Daily Discussion, August 18, 2020

    Posted: 18 Aug 2020 12:00 AM PDT

    Please utilize this sticky thread for all general Bitcoin discussions! If you see posts on the front page or /r/Bitcoin/new which are better suited for this daily discussion thread, please help out by directing the OP to this thread instead. Thank you!

    If you don't get an answer to your question, you can try phrasing it differently or commenting again tomorrow.

    Join us in the r/Bitcoin Chatroom!

    Please check the previous discussion thread for unanswered questions.

    submitted by /u/rBitcoinMod
    [link] [comments]

    Blockstream Satellite celebrates its 3rd year anniversary!

    Posted: 17 Aug 2020 07:37 PM PDT

    Bitcoin Knots 0.20.1.knots20200815 released! ��

    Posted: 17 Aug 2020 09:08 PM PDT

    Power of lightning .. at a glance.

    Posted: 17 Aug 2020 02:45 PM PDT

    Why invest in Bitcoin? 1. Bitcoin critics turning a 180° 2. Bitcoin is #34 in world currencies, beating New Zealand 3. Russia Dumping U.S. Dollar 4. Warren Buffet sells Banks buys GOLD�� 5. It's just getting started ��

    Posted: 17 Aug 2020 06:05 PM PDT

    “Most bitcoins already cost at least $100k, but probably more like $10 million.” -Michael Goldstein

    Posted: 17 Aug 2020 11:10 PM PDT

    What are your thoughts on this take? -Michael Goldstein's tweet

    submitted by /u/undergroundinvesting
    [link] [comments]

    If you thought MicroStrategy's Bitcoin buy was a big deal, just wait for JP Morgan Chase to allocate a % of their cash into Bitcoin. It's going to happen.

    Posted: 17 Aug 2020 10:19 AM PDT

    Bitcoin has surpassed $ 12,000 and is heading for the Moon

    Posted: 17 Aug 2020 09:52 AM PDT

    I finally managed to get my stupid lightning node working!

    Posted: 18 Aug 2020 01:03 AM PDT

    Bitcoin up 43% since Paul Krugman congratulated himself on predicting it's "decline" in 2018

    Posted: 18 Aug 2020 03:12 AM PDT

    BITCOIN above $12,000 after an initial rejection

    Posted: 17 Aug 2020 06:34 AM PDT

    judica's overarching goal is to fiscally empower humanity.

    Posted: 18 Aug 2020 01:46 AM PDT

    A way around the bank?

    Posted: 17 Aug 2020 10:05 PM PDT

    So my bank won't let me purchase bitcoins, ny best guess as a way around this is to buy a prepaid card to purchase them is this ok or not just wondering ?

    submitted by /u/fruithat123
    [link] [comments]

    Bitcoin Hits Highest in 13 Months as 2020 Rally Gathers Steam

    Posted: 17 Aug 2020 04:22 PM PDT

    China and Russia ditch dollar in move towards ‘financial alliance’

    Posted: 17 Aug 2020 12:21 PM PDT
    Read more
    at

    No comments:

    Post a Comment