From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E149F57 for ; Wed, 24 Jan 2018 18:51:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44F93356 for ; Wed, 24 Jan 2018 18:51:30 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id f71so10302476wmf.0 for ; Wed, 24 Jan 2018 10:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kiMs4hZGVeB9KlsOHIQdbOq8loIJPSnnPLKS+cwPW2g=; b=nSjALka6k7I3Dy5sFzR2msMIkWoZ/aljU2mofl7XcgGB/WDA7HDbaSt/FKhsIBUcks xnOu/X0kT5tk24tgqiN4n69cFaZXLJPVnGSPorlVoiZ6GoDqkCPsb+PGXaexDc2kbJem RHzZVmYMa8pMh/Aq3njGfF6vOQnAlBLepT0e8TV1liPnYu208BsnIIpc3i8LK9RJVlqY 986TcM4aClqI9ubJqd0Y91toJ1ycbtQ8J0gpUStSs6ASllP5mlPx5oiAQK83wyrY1iDZ /FPPywgVQ8zAE2wuJpqQogcEoGqd06kSsS3Q7xgvqk18HZb9LzYq9Qq8IvgMjIphjY15 t8DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kiMs4hZGVeB9KlsOHIQdbOq8loIJPSnnPLKS+cwPW2g=; b=jKJX7pm5KTtUIBdjy7x0f7wYQcqhlCuMO9mTo84N0ss0ZrirjBu/eA/d8lXekGMiNL AvC/jeej50AAcanR5oBgLbouRX+jfNRH4S0C8ibvt+deH2ZRnEOp3kADfBFQ0X3jz+Op aSER1wv4g/cOq2NyIb811UMmbyAeQ2yNVh4qrdILx6h6ZRrD9ZB/naL29bIu8HMbXqnr h4T0/uOUte6LMHM12bnsplmztqKMXQmi416Nr1guCUWCwqTSRVaMg+80D2eKhYiQHRjL 5lBS4ZwboWat44TGvX9thcla3bLduT4xQJHMRazhjjxEBo7ECoZ+ORQ/5p8vS26a+ezQ 2yZA== X-Gm-Message-State: AKwxytfWLPI9hP5mbdViuI12EDU7UX/C5pN0/uowpfuT+VolOuArUZQ/ NeZdL+THUfr5DUyney7kwtzwjrO1j2sJeGsFn0E= X-Google-Smtp-Source: AH8x225mL7dq6eT1oyuVZs0H6veBLMrAZkTE4TEsCuyQnXZ34T8Wf8qOxss3IkcRsMRGTHXA9Mo3B+oHv5snzQoOkFc= X-Received: by 10.80.151.137 with SMTP id e9mr25941559edb.102.1516819888819; Wed, 24 Jan 2018 10:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 10:51:27 -0800 (PST) Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 10:51:27 -0800 (PST) In-Reply-To: <1516808291.4277.25.camel@mmci.uni-saarland.de> References: <20180123064419.GA1296@erisian.com.au> <20180123222229.GA3801@erisian.com.au> <1516808291.4277.25.camel@mmci.uni-saarland.de> From: Natanael Date: Wed, 24 Jan 2018 19:51:27 +0100 Message-ID: To: Tim Ruffing , Bitcoin Dev Content-Type: multipart/alternative; boundary="f403045c268ea952e705638a26ca" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 18:51:31 -0000 --f403045c268ea952e705638a26ca Content-Type: text/plain; charset="UTF-8" Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Okay, I think my proposal was wrong... This looks better (feel free to break again): 1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the blockchain Then the tx in the first valid commitment wins. If the attacker intercepts classic_pk, it won't help him. He cannot create the first valid commitment, because it is created already. (The reason is that the decommitment is canonical now; for all commitments, the decommitment is just classic_pk.) That's not the type of attack I'm imagining. Both versions of your scheme are essentially equivalent in terms of this attack. Intended steps: 1: You publish a hash commitment. 2: The hash ends up in the blockchain. 3: You publish the transaction itself, and it matches the hash commitment. 4: Because it matches, miners includes it. It's now in the blockchain. Attack: 1: You publish a hash commitment. 2: The hash ends up the blockchain. 3: You publish the transaction itself, it matches the hash commitment. 4: The attacker mess with the network somehow to prevent your transaction from reaching the miners. 5: The attacker cracks your keypair, and makes his own commitment hash for his own theft transaction. 6: Once that commitment is in the blockchain, he publishes his own theft transaction. 7: The attacker's theft transaction gets into the blockchain. 8 (optionally): The miners finally see your original transaction with the older commitment, but now the theft transaction can't be undone. There's nothing to do about it, nor a way to know if it's intentional or not. Anybody not verifying commitments only sees a doublespend attempt. --- More speculation, not really a serious proposal: I can imagine one way to reduce the probability of success for the attack by publishing encrypted transactions as the commitment, to then publish the key - the effect of this is that the key is easier to propagate quickly across the network than a full transaction, making it harder to succeed with a network based attack. This naive version by itself is however a major DoS vector against the network. You could, in some kind of fork, redefine how blocks are processed such that you can prune all encrypted transactions that have not had the key published within X blocks. The validation rules would work such that to publish the key for an encrypted transaction in a new block, that transaction must both be recent enough, be valid by itself, and also not conflict with any other existing plaintext / decrypted transactions in the blockchain. Blocks wouldn't necessarily even need to include the encrypted transactions during propagation. This works because encrypted transactions have zero effect until the key is published. In this case you'd effectively be required to publish your encrypted transaction twice to ensure the raw data isn't lost, once to get into a block and again together with the key to get it settled. Since miners will likely keep at least the most recent encrypted transactions cached to speed up validation, this is faster to settle than to publish the committed transaction as mentioned in the beginning. This increases your chances to get your key into the blockchain to settle your transaction before the attacker completes his attack, versus pushing a full transaction that miners haven't seen before. This version would still allow DoS against miners caching all encrypted transactions. However, if efficient Zero-knowledge proofs became practical then you can use one to prove your encrypted transaction valid, even against the UTXO set and in terms of not colliding with existing commitments - in this case the DoS attack properties are nearly identical to standard transactions. If you want to change a committed transaction, you'd need to let the commitment expire. --f403045c268ea952e705638a26ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev&qu= ot; <bitcoin-de= v@lists.linuxfoundation.org>:
Okay, I think = my proposal was wrong...

This looks better (feel free to break again):
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the blockchain

Then the tx in the first valid commitment wins. If the attacker
intercepts classic_pk, it won't help him. He cannot create the first valid commitment, because it is created already. (The reason is that
the decommitment is canonical now; for all commitments, the
decommitment is just classic_pk.)

That's not the type of attack I&= #39;m imagining. Both versions of your scheme are essentially equivalent in= terms of this attack.=C2=A0

Intended steps:=C2=A0
1: You publish a hash com= mitment.=C2=A0
2: The hash ends up in the blockchain= .=C2=A0
3: You publish the transaction itself, and i= t matches the hash commitment.=C2=A0
4: Because it m= atches, miners includes it. It's now in the blockchain.=C2=A0

Attack:=C2=A0
1: You publish a hash commitment.=C2=A0
2: The h= ash ends up the blockchain.=C2=A0
3: You publish the= transaction itself, it matches the hash commitment.=C2=A0
4: The attacker mess with the network somehow to prevent your transa= ction from reaching the miners.=C2=A0
5: The attacke= r cracks your keypair, and makes his own commitment hash for his own theft = transaction.=C2=A0
6: Once that commitment is in the= blockchain, he publishes his own theft transaction.=C2=A0
7: The attacker's theft transaction gets into the blockchain.=C2= =A0
8 (optionally): The miners finally see your orig= inal transaction with the older commitment, but now the theft transaction c= an't be undone. There's nothing to do about it, nor a way to know i= f it's intentional or not. Anybody not verifying commitments only sees = a doublespend attempt.=C2=A0

---

More speculatio= n, not really a serious proposal:=C2=A0

I can imagine one way to reduce the probability of success = for the attack by publishing encrypted transactions as the commitment, to t= hen publish the key - the effect of this is that the key is easier to propa= gate quickly across the network than a full transaction, making it harder t= o succeed with a network based attack. This naive version by itself is howe= ver a major DoS vector against the network.=C2=A0
You could, in some kind of fork, redefine how blo= cks are processed such that you can prune all encrypted transactions that h= ave not had the key published within X blocks. The validation rules would w= ork such that to publish the key for an encrypted transaction in a new bloc= k, that transaction must both be recent enough, be valid by itself, and als= o not conflict with any other existing plaintext / decrypted transactions i= n the blockchain.=C2=A0

= Blocks wouldn't necessarily even= need to include the encrypted transactions during propagation.=C2=A0This works because encrypted transa= ctions have zero effect until the key is published.=C2=A0In=C2=A0this case you'd effectively = be required to publish your encrypted transaction twice to ensure the raw d= ata isn't lost, once to get into a block and again together with the ke= y to get it settled.=C2=A0

Since miners will likely keep at least the most recent encrypted transac= tions cached to speed up validation, this is faster to settle than to publi= sh the committed transaction as mentioned in the beginning. This increases = your chances to get your key into the blockchain to settle your transaction= before the attacker completes his attack, versus pushing a full transactio= n that miners haven't seen before.=C2=A0

This version would still allow DoS against miners cach= ing all encrypted transactions. However, if efficient Zero-knowledge proofs= became practical then you can use one to prove your encrypted transaction = valid, even against the UTXO set and in terms of not colliding with existin= g commitments - in this case the DoS attack properties are nearly identical= to standard transactions.=C2=A0
If you want to chan= ge a committed transaction, you'd need to let the commitment expire.=C2= =A0
--f403045c268ea952e705638a26ca--