diff options
| author | Alex Schoof <alex.schoof@gmail.com> | 2021-06-28 13:58:47 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-28 17:59:01 +0000 |
| commit | 809bd2d5a4fc60a68cd7a9c73a43862903d85a19 (patch) | |
| tree | 0c8f542f28be8b2c30c7e837dcb9d09895cb1e86 | |
| parent | c45798202b427151a6f14c57a41bb3ba08f1341a (diff) | |
| download | pi-bitcoindev-809bd2d5a4fc60a68cd7a9c73a43862903d85a19.tar.gz pi-bitcoindev-809bd2d5a4fc60a68cd7a9c73a43862903d85a19.zip | |
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
| -rw-r--r-- | ae/212d3fbfd130847153607f2bbab88fb00c6297 | 384 |
1 files changed, 384 insertions, 0 deletions
diff --git a/ae/212d3fbfd130847153607f2bbab88fb00c6297 b/ae/212d3fbfd130847153607f2bbab88fb00c6297 new file mode 100644 index 000000000..0dc33deb6 --- /dev/null +++ b/ae/212d3fbfd130847153607f2bbab88fb00c6297 @@ -0,0 +1,384 @@ +Return-Path: <alex.schoof@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 27A94C000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Jun 2021 17:59:01 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 072E4402AA + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Jun 2021 17:59:01 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 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, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.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 8Fy-kdhimk4l + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Jun 2021 17:58:59 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com + [IPv6:2607:f8b0:4864:20::32d]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 4C4BD4017D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Jun 2021 17:58:59 +0000 (UTC) +Received: by mail-ot1-x32d.google.com with SMTP id + m6-20020a9d1d060000b029044e2d8e855eso17734012otm.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Jun 2021 10:58:59 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=y1dU7sigqjk1U1kf4RDG05slMMM34pEJh/boQoOzCdo=; + b=KuKHqrxj4quTDVceEHL34mD5c4KI45qlnTBN2x9U0SVwvPsHrNgK9MhJLua3IZ98Fr + 69xppZMkIACU7q16R50uF/1cGg6+Zp2alBSS5deaS/Ye18/LzkrMORpA6Bkc2thTRHxV + bjrW6KLrZ7RbuHfg9NEI6/KSJ6V13rDbYTonSQCaEQ4ZpKx8tisdNyq8uLHOjpSOWK/9 + 2yP3t2SHbMKA0oo9iDZ/+Nl7NEgO0PSBEdu2hspWGH8KylgJgvDP9eo/Wi8f76dAWCnL + vRTe3Q6FVPI9Fn+EUSsj17dWHsYQDai9TfbEeEjZq+rZbIeLl2hdifEP+HrIeGhMtyGI + 9oqA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=y1dU7sigqjk1U1kf4RDG05slMMM34pEJh/boQoOzCdo=; + b=Ky8bJKe/M+OBO3UnJ55Tgo28RwTM46KrErknX0xp9MChjCb0/iTNRyoilkfn75FDVY + hsPgC0YLsw1OK/yeXByp3tPmuoe19L59fg54WlnAA7FiWeeiNqlvjcWYh8nbd5jutI/f + Y9dAnY7QvDSoyRiP7WByd+waHePZNkQZXfGInzkicgXCUADGnQMQiLVAM8gs+sAhn+GJ + z7uEtUXBbWl5CmN2RX+uW1vhT9ufsjhFIlg1PMXYM7JPTtpihs7rT1goCZWXemhheebl + YUgX1f8cRvus8o7geZcFHEgqDxJlh7YhRiEnhpWebvkY8xQvT7gynOaeEVjMkVLPjXES + cCJQ== +X-Gm-Message-State: AOAM531hu7X+ESePAqKF2/c0ZjZnHMY4dhclLM3Zqqn1YrHX/zraOhur + b6gYTSTNU7y8n0PF/Sv4k1NFgDO1dxSPdvZQCcklyQEJp7M= +X-Google-Smtp-Source: ABdhPJy8syrCzGXU+dW8zEQmDtSLZRz7HMcdKMTb+vvl7Rmpm8OjDrW8Q/pq57zI3VNzQcDdMo8N/0G0VHmq3AeO8NI= +X-Received: by 2002:a9d:6d17:: with SMTP id o23mr698874otp.13.1624903138072; + Mon, 28 Jun 2021 10:58:58 -0700 (PDT) +MIME-Version: 1.0 +References: <bea8122aea550f1141170829aac252af@riseup.net> + <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> + <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> + <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com> + <edee179d873eb9db551204561db17e90@riseup.net> + <A5gXRNtpLIWjF8Uq7CRLiwl9mb1eEY7IW7AQfQL_7uW9cXCKLn6FdOyYKBq1Dl1L-vgCBwFUgC873WyEEpS6K9F7ct4mdwRMKco01xsWhHg=@protonmail.com> + <c2e7b6336190c5dae6383abb284c335b@riseup.net> + <zs9XYSRzwoyhcfqXvyXG67bZqNTUt5_0DZwjrsyEKrvFbaxhX6jEAXBXPP01HnkxgApU8oGMXdOBVdgSHXBFrKAYLzCg_OmoIvO2EfsqJJg=@protonmail.com> + <16131549ac084b58fc6cde894e43babe@riseup.net> +In-Reply-To: <16131549ac084b58fc6cde894e43babe@riseup.net> +From: Alex Schoof <alex.schoof@gmail.com> +Date: Mon, 28 Jun 2021 13:58:47 -0400 +Message-ID: <CA+2b5C2m6m2-OHKa7dVGiQcQG-dv82xQQQc45QrmeDz6HS2skQ@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + raymo@riseup.net +Content-Type: multipart/alternative; boundary="00000000000056db5f05c5d73e74" +X-Mailman-Approved-At: Mon, 28 Jun 2021 19:04:36 +0000 +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: Mon, 28 Jun 2021 17:59:01 -0000 + +--00000000000056db5f05c5d73e74 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hey Raymo, + +Here=E2=80=99s a scenario: + +Alice has one UTXO. + +Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives whatever +goods and services to Alice. + +Alice then goes and spends that UTXO to Charlie with a higher fee than the +GT she sent to Bob. Charlie has no idea that Bob exists, because he gets a +valid UTXO. Bob can try to publish the GT, but if Alice crafts the fees +right, the TX to Charlie will be confirmed first. Alice now has goods from +both Bob and Charlie, and has only paid one of them. She has is able to +double spend because: (1) the gossip network you describe for sabu only +protects people if everyone is on sabu and playing by the rules, it does +not prevent spending outside of sabu; and (2) there is nothing encumbering +the onchain UTXO and preventing it from being spent outside of a sabu +payment. + +The reason people keep brining up Lightning is because Lightning solves +this problem by having a channel-open involve locking funds in a 2-of-2 +multisig, preventing them from being spent outside of lightning until the +channel is torn down. + +If there is nothing stopping someone from spending onchain funds outside of +the context of your system, then your system does not prevent double spends= +. + +Hope that explanation helps. + +Alex + +On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> +> +> > What prevents the creditor from signing a transaction that is neither a +> valid MT nor a GT? +> Please stop comparing Sabu and Lightning. Otherwise, it won't let you +> true understanding of Sabu. +> In Sabu protocol, only the issuer (the UTXO owner) can sign the +> transaction and decide how much money goes to whom. The engaged UTXO(s) +> belonged to issuer and the creditor never put UTXO in transaction, thus +> never can sign the transaction because he has no ownership on the used +> UTXOs. +> As I already wrote in paper, the issuer creates and signs a transaction +> and delivers it to creditor(s). If a creditor intends to send all or +> part of his money to another person (AKA spending his money), he will +> ask for a new signed transaction from issuer, in which a part of his +> credit will transfer to another creditor. +> +> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of +> doc-watchers which maybe it was the cause you always compare it to +> Lightning. +> I am not presenting lightning neither condemning it. +> I am presenting Sabu protocol. +> Please let concentrate on how Sabu works or not works. +> +> +> +> On 2021-06-28 15:28, ZmnSCPxj wrote: +> > Good morning Raymo, +> > +> >> Hi ZmnSCPxj, +> >> +> >> Why you get the signal =E2=80=9Ctrust the Gazin wallet=E2=80=9D? +> >> Sabu is a protocol and the Gazin wallet will be an implementation of +> >> that protocol. We will implement it in react-native language to suppor= +t +> >> both Android and iPhone. Of course it will be open source and GPL3. +> >> Here is the repository and yet is empty :) +> >> https://github.com/raymaot/Gazin +> >> +> >> I wonder why you do not look carefully into the proposal! IMHO the Sab= +u +> >> will be far better than Lightning. +> >> Can=E2=80=99t you see the fact that in Sabu you do not need open and c= +lose +> >> channels ever? Can you imagine only this feature how dramatically +> >> decrease the transactions cost and how increase the distribution of +> >> nodes and improve privacy level? it makes every mobile wallet act like= + a +> >> lightning network. +> >> Did you note the fact that in Sabu protocol there is no routing? And t= +he +> >> only people knew about a transaction are issuer and creditor? No one +> >> else won=E2=80=99t be aware of transactions and million transactions p= +er second +> >> can be sent and received and repeal dynamically without any footprint = +on +> >> any DLT? +> >> +> >> The English is not my mother language and probably my paper is not a +> >> smooth and easy to read paper, but these are not good excuse to not ev= +en +> >> reading a technical paper carefully and before understanding it or at +> >> least trying to understanding it start to complaining. +> > +> > +> > What prevents the creditor from signing a transaction that is neither +> > a valid MT nor a GT? +> > +> > Nothing. +> > +> > In Lightning, sure one side can sign a transaction that is not a valid +> > commitment transaction, but good luck getting the other side to *also* +> > sign the transaction; it will not. +> > Thus, you need n-of-n. +> > +> > 1-of-1 is simply not secure, full stop, you need to redesign the whole +> > thing to use *at least* 2-of-2. +> > At which point you will have reinvented Lightning. +> > +> > Otherwise, you are simply trusting that the wallet is implemented +> > correctly, and in particular, that any creditor will not simply insert +> > code in your open-source software to sign invalid transactions. +> > +> > With a 1-of-1, any invalid-in-Sabu transaction can still be valid in +> > the Bitcoin blockchain layer, thus the scheme is simply insecure. +> > +> > Features are meaningless without this kind of basic trust-minimization +> security. +> > +> > Regards, +> > ZmnSCPxj +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +--=20 + + +Alex Schoof + +--00000000000056db5f05c5d73e74 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">Hey Raymo,</div><div dir=3D"auto"><br></div><div dir=3D"a= +uto">Here=E2=80=99s a scenario:=C2=A0</div><div dir=3D"auto"><br></div><div= + dir=3D"auto">Alice has one UTXO.=C2=A0</div><div dir=3D"auto"><br></div><d= +iv dir=3D"auto">Suppose Alice sends Bob an MT and a GT over Sabu, and Bob g= +ives whatever goods and services to Alice.=C2=A0</div><div dir=3D"auto"><br= +></div><div dir=3D"auto">Alice then goes and spends that UTXO to Charlie wi= +th a higher fee than the GT she sent to Bob. Charlie has no idea that Bob e= +xists, because he gets a valid UTXO. Bob can try to publish the GT, but if = +Alice crafts the fees right, the TX to Charlie will be confirmed first. Ali= +ce now has goods from both Bob and Charlie, and has only paid one of them. = +She has is able to double spend because: (1) the gossip network you describ= +e for sabu only protects people if everyone is on sabu and playing by the r= +ules, it does not prevent spending outside of sabu; and (2) there is nothin= +g encumbering the onchain UTXO and preventing it from being spent outside o= +f a sabu payment.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">= +The reason people keep brining up Lightning is because Lightning solves thi= +s problem by having a channel-open involve locking funds in a 2-of-2 multis= +ig, preventing them from being spent outside of lightning until the channel= + is torn down.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">If = +there is nothing stopping someone from spending onchain funds outside of th= +e context of your system, then your system does not prevent double spends.<= +/div><div dir=3D"auto"><br></div><div dir=3D"auto">Hope that explanation he= +lps.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Alex</div><di= +v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On M= +on, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev <<a href=3D"mailto:bit= +coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</= +a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> +<br> +> What prevents the creditor from signing a transaction that is neither = +a valid MT nor a GT?<br> +Please stop comparing Sabu and Lightning. Otherwise, it won't let you<b= +r> +true understanding of Sabu. <br> +In Sabu protocol, only the issuer (the UTXO owner) can sign the<br> +transaction and decide how much money goes to whom. The engaged UTXO(s)<br> +belonged to issuer and the creditor never put UTXO in transaction, thus<br> +never can sign the transaction because he has no ownership on the used<br> +UTXOs. <br> +As I already wrote in paper, the issuer creates and signs a transaction<br> +and delivers it to creditor(s). If a creditor intends to send all or<br> +part of his money to another person (AKA spending his money), he will<br> +ask for a new signed transaction from issuer, in which a part of his<br> +credit will transfer to another creditor.<br> +<br> +The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of<br> +doc-watchers which maybe it was the cause you always compare it to<br> +Lightning. <br> +I am not presenting lightning neither condemning it. <br> +I am presenting Sabu protocol. <br> +Please let concentrate on how Sabu works or not works.<br> +<br> +<br> +<br> +On 2021-06-28 15:28, ZmnSCPxj wrote:<br> +> Good morning Raymo,<br> +> <br> +>> Hi ZmnSCPxj,<br> +>><br> +>> Why you get the signal =E2=80=9Ctrust the Gazin wallet=E2=80=9D?<b= +r> +>> Sabu is a protocol and the Gazin wallet will be an implementation = +of<br> +>> that protocol. We will implement it in react-native language to su= +pport<br> +>> both Android and iPhone. Of course it will be open source and GPL3= +.<br> +>> Here is the repository and yet is empty :)<br> +>> <a href=3D"https://github.com/raymaot/Gazin" rel=3D"noreferrer" ta= +rget=3D"_blank">https://github.com/raymaot/Gazin</a><br> +>><br> +>> I wonder why you do not look carefully into the proposal! IMHO the= + Sabu<br> +>> will be far better than Lightning.<br> +>> Can=E2=80=99t you see the fact that in Sabu you do not need open a= +nd close<br> +>> channels ever? Can you imagine only this feature how dramatically<= +br> +>> decrease the transactions cost and how increase the distribution o= +f<br> +>> nodes and improve privacy level? it makes every mobile wallet act = +like a<br> +>> lightning network.<br> +>> Did you note the fact that in Sabu protocol there is no routing? A= +nd the<br> +>> only people knew about a transaction are issuer and creditor? No o= +ne<br> +>> else won=E2=80=99t be aware of transactions and million transactio= +ns per second<br> +>> can be sent and received and repeal dynamically without any footpr= +int on<br> +>> any DLT?<br> +>><br> +>> The English is not my mother language and probably my paper is not= + a<br> +>> smooth and easy to read paper, but these are not good excuse to no= +t even<br> +>> reading a technical paper carefully and before understanding it or= + at<br> +>> least trying to understanding it start to complaining.<br> +> <br> +> <br> +> What prevents the creditor from signing a transaction that is neither<= +br> +> a valid MT nor a GT?<br> +> <br> +> Nothing.<br> +> <br> +> In Lightning, sure one side can sign a transaction that is not a valid= +<br> +> commitment transaction, but good luck getting the other side to *also*= +<br> +> sign the transaction; it will not.<br> +> Thus, you need n-of-n.<br> +> <br> +> 1-of-1 is simply not secure, full stop, you need to redesign the whole= +<br> +> thing to use *at least* 2-of-2.<br> +> At which point you will have reinvented Lightning.<br> +> <br> +> Otherwise, you are simply trusting that the wallet is implemented<br> +> correctly, and in particular, that any creditor will not simply insert= +<br> +> code in your open-source software to sign invalid transactions.<br> +> <br> +> With a 1-of-1, any invalid-in-Sabu transaction can still be valid in<b= +r> +> the Bitcoin blockchain layer, thus the scheme is simply insecure.<br> +> <br> +> Features are meaningless without this kind of basic trust-minimization= + security.<br> +> <br> +> Regards,<br> +> ZmnSCPxj<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" = +data-smartmail=3D"gmail_signature"><br><br>Alex Schoof</div> + +--00000000000056db5f05c5d73e74-- + |