diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2021-06-27 04:53:52 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-27 04:54:08 +0000 |
| commit | 8dd1ad492aa45cfb0823e241ba2d5941170c483e (patch) | |
| tree | 27698ab813f29255e4fbe21abdb90bc05eaba0c6 /9c | |
| parent | 17366350401060f7a1c660a0f7a34a90cacbc131 (diff) | |
| download | pi-bitcoindev-8dd1ad492aa45cfb0823e241ba2d5941170c483e.tar.gz pi-bitcoindev-8dd1ad492aa45cfb0823e241ba2d5941170c483e.zip | |
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
Diffstat (limited to '9c')
| -rw-r--r-- | 9c/05d0ee250219f70450de66d1268bd84fee6a5e | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/9c/05d0ee250219f70450de66d1268bd84fee6a5e b/9c/05d0ee250219f70450de66d1268bd84fee6a5e new file mode 100644 index 000000000..d77575b3d --- /dev/null +++ b/9c/05d0ee250219f70450de66d1268bd84fee6a5e @@ -0,0 +1,152 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id B10C0C000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 04:54:08 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 89EA44033B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 04:54:08 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.601 +X-Spam-Level: +X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (1024-bit key) header.d=protonmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Rr8qO4JHJn2E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 04:54:06 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch + [185.70.40.138]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 5BDC4402C6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Jun 2021 04:54:06 +0000 (UTC) +Date: Sun, 27 Jun 2021 04:53:52 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail; t=1624769642; + bh=Y266dpzedqlN+nv/Ldl0kw7+ZbJN91IstvSnKWdhc/k=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; + b=aaOl5Cy1TmhTCxqSKazzjtYEScfthArguUG/410A4LP2Uq37xCNqX6pt7IhRqmT+f + w8GcdWzZzW1hpb+Ky2Cj/O9ONj9MhKQo/RtILJA4JjevXYdNsgIP48TRkf4GqHPRQu + 8oiv4vA+fEqlyYZleDwna5lssvPck8/fyI2Lx6Cs= +To: "raymo@riseup.net" <raymo@riseup.net> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com> +In-Reply-To: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> +References: <bea8122aea550f1141170829aac252af@riseup.net> + <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> + <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Boost Bitcoin circulation, + Million Transactions Per Second with stronger privacy +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 27 Jun 2021 04:54:08 -0000 + +Good morning Raymo, + + +> Good morning ZmnSCPxj +> Sorry for late reply. +> +> > Guarantee Transactions (GT) being higher-fee is not assured. +> +> The question is =E2=80=9Cassuring what?=E2=80=9D. +> The whole point of my proposal is the fact that issuers and creditors +> act rationally and won't harm their selves. The numbers (input and +> output amounts), the relation between inputs and outputs amounts, the +> minimum and maximum of inputs and outputs amounts, and conditions of a +> valid trans-action in Sabu protocol are all designed precisely to +> leading the rational users toward the making profit from the system. And +> irrationals (either issuer or creditor) can harm the others and +> inevitably in con-sequence will hurt themselves too. So, there is a fair +> and just transaction (MT). +> The creditor can send the GT to Bitcoin network and lose 70% of his +> money and damage 15% of is-suer money! +> Vice versa the issuer can send GT to Bitcoin network and harm itself 15% +> in cost of hurt creditors 70% which is none sense. Or issuer can pay +> even more money directly to miner and hurt itself even more which is +> even more irrational! Or the miner will ignore the transaction fees of a +> GT and put the fraudulent transaction in next block, which I cannot +> imagine a miner that pass up his legal and legiti-mate income in favor +> of a greedy issuer! +> Please write me a scenario (preferably with clear amount of inputs and +> outputs) by which the cheater (either issuer or creditor) gains more +> profit than playing honestly. +> Only in this case we can accept your claim about weakness of protocol. +> +> > Every offchain protocol needs the receiver as a signatory to any unconf= +irmed transaction. the receiver must be a signatory --- the receiver cannot= + trust an unconfirmed transaction where the spent UTXO has an alternate bra= +nch that does not have the receiver as a signatory. +> +> I intentionally decided to not using 2 of 2 signature, because I didn't +> want to fall in same trap as Light-ening. I wanted to avoid this long +> drilling 2 of 2 signings and routing. Instead, I just proposed to +> cre-ate and sign a valid Bitcoin transaction between only 2 people in a +> pure-peer-to-peer communication. The only signer is the issuer (the UTXO +> owner). +> Again, same logic. Please write me a scenario by which the cheater +> (issuer or creditor) can cheat this only-issuer-signed transactions and +> gains more profit than playing honest. Due to numbers and trans-action +> restrictions and the insignificance of the amount of each transaction +> this scenario of fraud will fail too. + +As the issuer is the only one signing, it can trivially create a self-payin= +g transaction by itself that is neither a valid MT nor a valid GT. + +Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change output b= +ack to me. +After you hand over the equivalent of 1 BTC in other resources, I then crea= +te an alternative transaction, signed only by myself, paying 0.5 BTC to min= +ers and 1.5 BTC to myself, and since the fee is so high, the miners have ev= +ery incentive to mine it. + +Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain la= +yer requires that the *single* signer follow the protocol. +The point here is that a single signer can sign anything, including a trans= +action that is not an MT or a GT, but has arbitrary numbers that are neithe= +r a valid GT nor a valid MT. +That is the reason why every trust-minimized offchain system requires 2-of-= +2, somebody else has to countercheck the validity of a protocol that is *no= +t* directly on the blockchain. +The blockchain only cares about signature and timelock validity; it does no= +t care about (and check for validity) MTs and GTs. + +In essence, this is a trusted system where every creditor trusts every issu= +er to *only* sign GTs and MTs, thus uninteresting --- you might as well jus= +t use Coinbase as your offchain if you are going to inject trust. + +Now you can counterargue that you intend this system to be used for small p= +ayments and thus the fee for this non-MT non-GT clawback can approach the s= +ecurity levels you so carefully computed for GT and MT, but again --- the *= +largest* safe payment will vary depending on onchain mempool state, and if = +the mempool is almost empty, the largest safe payment will be much smaller = +than at other times. +This uncertainty is not handled well by most users, thus I think your UX wi= +ll be fairly awful. + +Regards, +ZmnSCPxj + |