Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1B0BC000C for ; Sat, 19 Jun 2021 21:14:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id BDE8C831A5 for ; Sat, 19 Jun 2021 21:14:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz4IwPRYUB2Z for ; Sat, 19 Jun 2021 21:14:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1CB7883168 for ; Sat, 19 Jun 2021 21:14:21 +0000 (UTC) Received: by mail-pj1-x102d.google.com with SMTP id o10-20020a17090aac0ab029016e92770073so7902027pjq.5 for ; Sat, 19 Jun 2021 14:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jbWsWd95ZoOHfLqKscSmA7V8s+C+1bcY8xIUxEh9Eng=; b=h4hlya4eoNbYr9fA0VlCPrcZGO1gOZBoNimg+teif2QebMR14l1ijPwoBxIJZK6CNt KDNdqPSw6vV15mEhAg+WjM2EAN/8DwYWygEJqpYztWuJQKVLiGnbRHN70Ev5YH+ZlhAh eLUnq14VwmGg6yzazG3VBzlExV7QxxycxUC21b1lRAcK6A2kX6oLC4JA/g4J1Re7OT0W 7U2RzBdkSHFQX91gg1sDZCmVEn8ceTNLMRtjLWahkZDTbxqE396nh1ee6KGzYTLR5Ayl JS0qx7RnYbleWmtYC6KamrFI0KJIN3DzMFkAGq2YIZ4aJDkQhR17BAiqRk3vMGWmctdM 6BUQ== 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=jbWsWd95ZoOHfLqKscSmA7V8s+C+1bcY8xIUxEh9Eng=; b=cvsW/9YZZjF0VTJqwDRna908gwP9bpP5GrHfz9QyssQU/dRNiU71zpy4UwgQHJMjob rSJUhrCktj7KKv4BuW1x6ybiKZfU7mZbPwc3vjjEhqnPLFzEYq7hQPhn+PxqI9XW9/O3 Q54kVxFp5ymZqD2U2+qN1plpGlp6Ibl6kwpiVS6k/I9PgQR1JgOYR+zCEF137p8g6j1j W2+iyz5cMKvt9FI+IoGVD4xeZWYGCABoI+m6eRFchhOraIWgtO+RJ1ID3lssLAug0HQe MrkIA6Az6VETGjnLkGWgOL/axQd7XdrR2aOwvNPs8zVfJhPe6Dd0WK9MfJZtISrMQo3v YiVA== X-Gm-Message-State: AOAM532KgVljKR1m3Xc+mrF9MFaRHHKoFXhwVq+Q/lhSeB4M8OkUREYB OZdXCuJK2fOgP8xbUeHfbv8oDTASsmi23Xf0nJ7fYV4= X-Google-Smtp-Source: ABdhPJypk1Nu0gRWXQis7SnN6iyQ0X9IpR1MiirC870B4qM1vDQqguaWbfKeBETZ1o+3xH3nPxLqMvKo4A+vFO7gikk= X-Received: by 2002:a17:90a:9a83:: with SMTP id e3mr20655859pjp.139.1624137260308; Sat, 19 Jun 2021 14:14:20 -0700 (PDT) MIME-Version: 1.0 References: <48ad47a84e52ace8ba897247103cabab@riseup.net> In-Reply-To: <48ad47a84e52ace8ba897247103cabab@riseup.net> From: Erik Aronesty Date: Sat, 19 Jun 2021 17:14:08 -0400 Message-ID: To: raymo@riseup.net Content-Type: multipart/alternative; boundary="000000000000779cba05c524ecf6" X-Mailman-Approved-At: Sat, 19 Jun 2021 22:14:30 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 21:14:22 -0000 --000000000000779cba05c524ecf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is no solution to preventing the fraud proofs. This is a known issue for Bitcoin in general. It basically caps your protocol at the cost of performing a fraud proof attack. Also I would ditch email in the core protocol, and use QR codes and device-to-device linking. client a shows QR client b scans QR (which is a pubkey) client b publishes his pubkey (gossip network), with POSK proof Then you add to your contact list. Email to be an optional clearly less secure layer but not part of the core protocol. It is vulnerable to mitm (how do you know who you're paying), but again for small values and known risks it's not terrible. On Fri, Jun 18, 2021 at 4:00 PM wrote: > > > Hi Alex, > > The 10 Sat fee is Sabu-transaction-fee and goes to issuers to > incentivize UTXO owners to put their money in system and prepare money > transfer service for the Creditors. pretty much like banks. > This number is my suggestion, but can be changed to something higher or > lesser or even being customized for each issuer(Banks with high fee and > more speed/reliability or less fee and less speed but more distributed). > > Typically Issuers put an UTXOs worth 40,000 Sat and issue a > debt-document(transaction) worth 20,000 or less. So issuer can use > thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document > (worth 20,000,000 debit) and earn significant Sabu-transaction-fee > daily. > No need to say the issuer also dictates the fiat to BTC exchange rate in > first step, and can earn even more benefits by selling BTC a little > higher than market price. The target would be penny savers which > potentially buy very small amount each time(teenagers or people with low > income specially). > > About your double-spend scenario please write a clear scenario and use > the conventional terms such as issuer, creditor, MT, GT, CT etc... to > study its feasibility. Maybe there are corner cases which I missed. So > we will fix it as well. > > About p2p Gossiping, you are right. There is latency but it doesn't hurt > the consensus on Sabu protocol. Please consider figure 7. inter > creditors Bitcoin transfer as an example. By the way in all money > transactions between issuer -> creditor or creditor->creditor, the > receiver wallet "always" controls the doc-watcher client to be ensure > the fact that the delivered debt-document(aka transaction) to receiver > wallet, already exist on the doc-watcher sites. If that particular > document exist in doc-watcher , the wallet consider it as a valid > transaction, otherwise creditor won't accept the deal as a settled deal. > > >I think you will end up reinventing a lot of the problems solved by bitcoin. > > No, that's not true. Because I proposed a complementary tool for Bitcoin > which came from a different point of view. Note the fact that Sabu > protocol realizes a different model of decentralization. In Sabu there > is no DLT at all and all consensus are between small set of users (most > of time between an issuer and a creditor). In Sabu there is no > obligation for everyone know everything about every transaction. Each > participant only knows about its interest. Alongside there is a gossip > mirroring of all transaction that flood to the clients a light weight > information of a tuple [UTXO, transaction-Merkle-root]. These gossip > nodes (doc-watchers) are not corruptible since it works in a simple > proof-of-existance (true-positive) model. And no one can mutilate it by > censor transactions. > > >Why did you pick email as the RPC mechanism to transfer these notes? > > First of all I have to explain a part of design spec. Each mobile wallet > has to have a fresh email address which is dedicated to Sabu protocol > activities. The wallet has access to this email address and read, delete > inbox or send emails. So the spam or spam filter problem is not the > case. > > In my opinion email is the ONLY neutral, free (non proprietary) and open > protocol/technology for communication in the world that its > infrastructure is well-established and is accessible all over the glob. > Even in countries with low internet speed. > I intentionally chose email as main communication mean. Because non > technical people can easily make an email address or change it > (comparing establish a website or use an static IP) and notify the > friends about new address and they can easily send and receive Bitcoin > just by knowing email addresses. Once the user install the > Sabu-supporter-wallet (called Gazin), he will config and record his 12 > seed words. The wallet also creates the PGP Pub/Priv key pair based on > these 12 words seeds and signs the wallet email address too. All are > take place behind the scene and user only sees its wallet is ready. So > these 12 worlds are users wealth protector and identity sovereignty as > well. User adds friends wallet email address or scan its QR code. The > rest is PGP encrypted emails(handshake, agreement and transactions) > between two wallets. No one needs to ask a central service to have an > account. Pure Cypher punk users can run their personal email server or > even better their freedombox https://freedomboxfoundation.org. So no one > can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his > account. The wallet owner can easily and fast immigrate to new email > address (or even different email service provider) and sign new address > and notify to his friends circle with no real barrier. > While these are all benefits of using email as a user identifier in > system, there could be some privacy issue in some levels. For example > most email service provider impose some sort of KYC or ask user mobile > number, but there are other providers which are respecting users > privacy. implicitly prevalence of Sabu users creates more demands for > this privacy-respector-companies, so these companies will be increased. > Another issue would be global passive spying or full-pipe project will > find who do transaction with who. Since communications are PGP encrypted > it won't be clear who is sender or receiver or how much is transferred > or even if they are really parties in a transaction or it is just a fake > noise connection! The forward secrecy also would be another issues. > although these are mostly the privacy issues rather than Sabu intrinsic > problems. > Some other disadvantage of email is latency, so some third parties would > easily provide the optional alternate communication services for wallet, > e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to > compensate the speed and/or privacy issues. These are all communication > means and the wallet can simply use one or more methods in parallel. > Later we will see the wallet users will choose which solution. Speed vs > privacy, sovereignty and independence. > > Regards > Raymo > > On 2021-06-18 13:44, Alex Schoof wrote: > > A few questions/comments: > > > > Why is there a 10 sat fee on each tx? Where does that fee go? > > > > I don=E2=80=99t think this design sufficiently protects against double > > spends by the =E2=80=9Cissuer=E2=80=9D (the person who actually has the= UTXO). > > Your guarantee tx mechanism only really covers the case where someone > > tries to double spend part of a UTXO balance (in other words, if the > > penalty lost is less than the value gained by doing a double spend, > > its worth it to double spend, and in a world where you=E2=80=99re passi= ng > > around digital IOUs, it=E2=80=99s easy to make it worth it). Later in t= he > > post, you mention that there will be a p2p network to gossip fund > > transfers and that will prevent an issuer from double spending. The > > problem there is that network latency is non-zero, large network > > partitions are both real and common, and nodes can come and go anytime > > (hardware failure, power failure, network partition healing, just > > because they feel like it, etc). Different nodes on the network might > > hear about different, conflicting transactions. Nodes will need a way > > to all come to consensus on what the right set of =E2=80=9Csent notes= =E2=80=9D is. > > I think you will end up reinventing a lot of the problems solved by > > bitcoin. > > > > Why did you pick email as the RPC mechanism to transfer these notes? > > Email is going to add variable amounts of latency and things like spam > > filters will cause issues. > > > > Alex > > > > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev > > wrote: > > > >> for very small transactions, this seems to make a hell of a lot of > >> sense. > >> > >> it's like lightning, but with no limits, no routing protocols... > >> everything is guaranteed by relative fees and the cost-of-theft. > >> > >> pretty cool. > >> > >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev > >> wrote: > >>> > >>> Hi, > >>> I have a proposal for improve Bitcoin TPS and privacy, here is the > >> post. > >>> > >> > > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-tr= ansactions-per-second-and-privacy-1eef8568d180 > >>> https://bitcointalk.org/index.php?topic=3D5344020.0 > >>> Can you please read it and share your idea about it. > >>> > >>> Cheers > >>> Raymo > >>> _______________________________________________ > >>> bitcoin-dev mailing list > >>> bitcoin-dev@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- > > > > Alex Schoof --000000000000779cba05c524ecf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is no solution to preventing the = fraud proofs.=C2=A0 This is a known issue for Bitcoin in general.=C2=A0 It = basically caps your protocol at the cost of performing a fraud proof attack= .

Also I would ditch ema= il in the core protocol, and use QR codes and device-to-device linking.
=

client a shows QR
client b scans QR (which is a pubkey)
client b publishes his pubkey (gossip network), with POSK proof

Then you add to your contact list.
<= div dir=3D"auto">
Email to be an optional clearl= y less secure layer but not part of the core protocol.=C2=A0 It is vulnerab= le to mitm (how do you know who you're paying), but again for small val= ues and known risks it's not terrible.



=




On Fri, Jun 18, 2021 at 4:00 PM <raymo@riseup.net> wrote:
>
>
> Hi Alex,
>
> The 10 Sat fee is Sabu-transaction-fee and goes to issuers to
> incentivize UTXO owners to put their money in system and prepare money=
> transfer service for the Creditors. pretty much like banks.
> This number is my suggestion, but can be changed to something higher o= r
> lesser or even being customized for each issuer(Banks with high fee an= d
> more speed/reliability or less fee and less speed but more distributed= ).
>
> Typically Issuers put an UTXOs worth 40,000 Sat and issue a
> debt-document(transaction) worth 20,000 or less. So issuer can use
> thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document=
> (worth 20,000,000 debit) and earn significant Sabu-transaction-fee
> daily.
> No need to say the issuer also dictates the fiat to BTC exchange rate = in
> first step, and can earn even more benefits by selling BTC a little > higher than market price. The target would be penny savers which
> potentially buy very small amount each time(teenagers or people with l= ow
> income specially).
>
> About your double-spend scenario please write a clear scenario and use=
> the conventional terms such as issuer, creditor, MT, GT, CT etc... to<= br> > study its feasibility. Maybe there are corner cases which I missed. So=
> we will fix it as well.
>
> About p2p Gossiping, you are right. There is latency but it doesn'= t hurt
> the consensus on Sabu protocol. Please consider figure 7. inter
> creditors Bitcoin transfer as an example. By the way in all money
> transactions between issuer -> creditor or creditor->creditor, t= he
> receiver wallet "always" controls the doc-watcher client to = be ensure
> the fact that the delivered debt-document(aka transaction) to receiver=
> wallet, already exist on the doc-watcher sites. If that particular
> document exist in doc-watcher , the wallet consider it as a valid
> transaction, otherwise creditor won't accept the deal as a settled= deal.
>
> >I think you will end up reinventing a lot of the problems solved b= y bitcoin.
>
> No, that's not true. Because I proposed a complementary tool for B= itcoin
> which came from a different point of view. Note the fact that Sabu
> protocol realizes a different model of decentralization. In Sabu there=
> is no DLT at all and all consensus are between small set of users (mos= t
> of time between an issuer and a creditor). In Sabu there is no
> obligation for everyone know everything about every transaction. Each<= br> > participant only knows about its interest. Alongside there is a gossip=
> mirroring of all transaction that flood to the clients a light weight<= br> > information of a tuple [UTXO, transaction-Merkle-root]. These gossip > nodes (doc-watchers) are not corruptible since it works in a simple > proof-of-existance (true-positive) model. And no one can mutilate it b= y
> censor transactions.
>
> >Why did you pick email as the RPC mechanism to transfer these note= s?
>
> First of all I have to explain a part of design spec. Each mobile wall= et
> has to have a fresh email address which is dedicated to Sabu protocol<= br> > activities. The wallet has access to this email address and read, dele= te
> inbox or send emails. So the spam or spam filter problem is not the > case.
>
> In my opinion email is the ONLY neutral, free (non proprietary) and op= en
> protocol/technology for communication in the world that its
> infrastructure is well-established and is accessible all over the glob= .
> Even in countries with low internet speed.
> I intentionally chose email as main communication mean. Because non > technical people can easily make an email address or change it
> (comparing establish a website or use an static IP) and notify the
> friends about new address and they can easily send and receive Bitcoin=
> just by knowing email addresses. Once the user install the
> Sabu-supporter-wallet (called Gazin), he will config and record his 12=
> seed words. The wallet also creates the PGP Pub/Priv key pair based on=
> these 12 words seeds and signs the wallet email address too. All are > take place behind the scene and user only sees its wallet is ready. So=
> these 12 worlds are users wealth protector and identity sovereignty as=
> well. User adds friends wallet email address or scan its QR code. The<= br> > rest is PGP encrypted emails(handshake, agreement and transactions) > between two wallets. No one needs to ask a central service to have an<= br> > account. Pure Cypher punk users can run their personal email server or=
> even better their freedombox https://freedomboxfound= ation.org. So no one
> can stop user from using this system(Bitcoin + Sabu + Gazin) or ban hi= s
> account. The wallet owner can easily and fast immigrate to new email > address (or even different email service provider) and sign new addres= s
> and notify to his friends circle with no real barrier.
> While these are all benefits of using email as a user identifier in > system, there could be some privacy issue in some levels. For example<= br> > most email service provider impose some sort of KYC or ask user mobile=
> number, but there are other providers which are respecting users
> privacy. implicitly prevalence of Sabu users creates more demands for<= br> > this privacy-respector-companies, so these companies will be increased= .
> Another issue would be global passive spying or full-pipe project will=
> find who do transaction with who. Since communications are PGP encrypt= ed
> it won't be clear who is sender or receiver or how much is transfe= rred
> or even if they are really parties in a transaction or it is just a fa= ke
> noise connection! The forward secrecy also would be another issues. > although these are mostly the privacy issues rather than Sabu intrinsi= c
> problems.
> Some other disadvantage of email is latency, so some third parties wou= ld
> easily provide the optional alternate communication services for walle= t,
> e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to > compensate the speed and/or privacy issues. These are all communicatio= n
> means and the wallet can simply use one or more methods in parallel. > Later we will see the wallet users will choose which solution. Speed v= s
> privacy, sovereignty and independence.
>
> Regards
> Raymo
>
> On 2021-06-18 13:44, Alex Schoof wrote:
> > A few questions/comments:
> >
> > Why is there a 10 sat fee on each tx? Where does that fee go?
> >
> > I don=E2=80=99t think this design sufficiently protects against d= ouble
> > spends by the =E2=80=9Cissuer=E2=80=9D (the person who actually h= as the UTXO).
> > Your guarantee tx mechanism only really covers the case where som= eone
> > tries to double spend part of a UTXO balance (in other words, if = the
> > penalty lost is less than the value gained by doing a double spen= d,
> > its worth it to double spend, and in a world where you=E2=80=99re= passing
> > around digital IOUs, it=E2=80=99s easy to make it worth it). Late= r in the
> > post, you mention that there will be a p2p network to gossip fund=
> > transfers and that will prevent an issuer from double spending. T= he
> > problem there is that network latency is non-zero, large network<= br> > > partitions are both real and common, and nodes can come and go an= ytime
> > (hardware failure, power failure, network partition healing, just=
> > because they feel like it, etc). Different nodes on the network m= ight
> > hear about different, conflicting transactions. Nodes will need a= way
> > to all come to consensus on what the right set of =E2=80=9Csent n= otes=E2=80=9D is.
> > I think you will end up reinventing a lot of the problems solved = by
> > bitcoin.
> >
> > Why did you pick email as the RPC mechanism to transfer these not= es?
> > Email is going to add variable amounts of latency and things like= spam
> > filters will cause issues.
> >
> > Alex
> >
> > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
> >
> >> for very small transactions, this seems to make a hell of a l= ot of
> >> sense.
> >>
> >> it's like lightning, but with no limits, no routing proto= cols...
> >> everything is guaranteed by relative fees and the cost-of-the= ft.
> >>
> >> pretty cool.
> >>
> >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:
> >>>
> >>> Hi,
> >>> I have a proposal for improve Bitcoin TPS and privacy, he= re is the
> >> post.
> >>>
> >>
> > https://raymo-49157.medium.com/ti= me-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy= -1eef8568d180
> >>> https://bitcointalk.= org/index.php?topic=3D5344020.0
> >>> Can you please read it and share your idea about it.
> >>>
> >>> Cheers
> >>> Raymo
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org<= /a>
> >>> https://l= ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org<= br> > >> https://lists= .linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >=C2=A0 --
> >
> > Alex Schoof
--000000000000779cba05c524ecf6--