path: root/ae/212d3fbfd130847153607f2bbab88fb00c6297

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 &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; 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>
&gt; 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&#39;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>
&gt; Good morning Raymo,<br>
&gt; <br>
&gt;&gt; Hi ZmnSCPxj,<br>
&gt;&gt;<br>
&gt;&gt; Why you get the signal =E2=80=9Ctrust the Gazin wallet=E2=80=9D?<b=
r>
&gt;&gt; Sabu is a protocol and the Gazin wallet will be an implementation =
of<br>
&gt;&gt; that protocol. We will implement it in react-native language to su=
pport<br>
&gt;&gt; both Android and iPhone. Of course it will be open source and GPL3=
.<br>
&gt;&gt; Here is the repository and yet is empty :)<br>
&gt;&gt; <a href=3D"https://github.com/raymaot/Gazin" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/raymaot/Gazin</a><br>
&gt;&gt;<br>
&gt;&gt; I wonder why you do not look carefully into the proposal! IMHO the=
 Sabu<br>
&gt;&gt; will be far better than Lightning.<br>
&gt;&gt; Can=E2=80=99t you see the fact that in Sabu you do not need open a=
nd close<br>
&gt;&gt; channels ever? Can you imagine only this feature how dramatically<=
br>
&gt;&gt; decrease the transactions cost and how increase the distribution o=
f<br>
&gt;&gt; nodes and improve privacy level? it makes every mobile wallet act =
like a<br>
&gt;&gt; lightning network.<br>
&gt;&gt; Did you note the fact that in Sabu protocol there is no routing? A=
nd the<br>
&gt;&gt; only people knew about a transaction are issuer and creditor? No o=
ne<br>
&gt;&gt; else won=E2=80=99t be aware of transactions and million transactio=
ns per second<br>
&gt;&gt; can be sent and received and repeal dynamically without any footpr=
int on<br>
&gt;&gt; any DLT?<br>
&gt;&gt;<br>
&gt;&gt; The English is not my mother language and probably my paper is not=
 a<br>
&gt;&gt; smooth and easy to read paper, but these are not good excuse to no=
t even<br>
&gt;&gt; reading a technical paper carefully and before understanding it or=
 at<br>
&gt;&gt; least trying to understanding it start to complaining.<br>
&gt; <br>
&gt; <br>
&gt; What prevents the creditor from signing a transaction that is neither<=
br>
&gt; a valid MT nor a GT?<br>
&gt; <br>
&gt; Nothing.<br>
&gt; <br>
&gt; In Lightning, sure one side can sign a transaction that is not a valid=
<br>
&gt; commitment transaction, but good luck getting the other side to *also*=
<br>
&gt; sign the transaction; it will not.<br>
&gt; Thus, you need n-of-n.<br>
&gt; <br>
&gt; 1-of-1 is simply not secure, full stop, you need to redesign the whole=
<br>
&gt; thing to use *at least* 2-of-2.<br>
&gt; At which point you will have reinvented Lightning.<br>
&gt; <br>
&gt; Otherwise, you are simply trusting that the wallet is implemented<br>
&gt; correctly, and in particular, that any creditor will not simply insert=
<br>
&gt; code in your open-source software to sign invalid transactions.<br>
&gt; <br>
&gt; With a 1-of-1, any invalid-in-Sabu transaction can still be valid in<b=
r>
&gt; the Bitcoin blockchain layer, thus the scheme is simply insecure.<br>
&gt; <br>
&gt; Features are meaningless without this kind of basic trust-minimization=
 security.<br>
&gt; <br>
&gt; Regards,<br>
&gt; 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--