path: root/54/ad81884e7da79741d8d571229d4a4e882dbf0b

Return-Path: <raymo@riseup.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18947C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Jun 2021 20:00:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EEFBD4063B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Jun 2021 20:00:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=riseup.net
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ukemICufShKj
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Jun 2021 20:00:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D6D2B40634
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Jun 2021 20:00:12 +0000 (UTC)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
 by mx1.riseup.net (Postfix) with ESMTPS id 4G68sm2pjxzDqvm;
 Fri, 18 Jun 2021 13:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1624046412; bh=T03D6jVNCR7zAZzTnJ1OQy7KnawsV1vc+8+Tdcgf/6I=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=FSNp3wRfNsQ88DfZ+fLA0+qYJp9Zh5SscodsZ3wKcynNNM56dflXyoF6Z0hNwvbBY
 4qS6tHxlGbYeL4JERY0HZkeblHhSFJ9tIZ/UuPz0OmONQM9LqCycLLZcxWCazL+UrL
 nZBGjHdUL198DmUTEqaSHvf14QAjCytI8Up69tlo=
X-Riseup-User-ID: CD218F2A3629232F2A7E2DBC6DDAAB2F7875D56FB9B3A58CC393B64AC2E2117C
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews1.riseup.net (Postfix) with ESMTPSA id 4G68sm1085z5vZ7;
 Fri, 18 Jun 2021 13:00:12 -0700 (PDT)
MIME-Version: 1.0
Date: Fri, 18 Jun 2021 13:00:12 -0700
From: raymo@riseup.net
To: Alex Schoof <alex.schoof@gmail.com>
In-Reply-To: <CA+2b5C3NiY7FcVbBYPKoMy4h6NbXTBY6jkJXhVU46ZorGvSBhQ@mail.gmail.com>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <CAJowKgLZPTAXe3LKVYbuA5zpi5V8AWDEnfLh9sqtWWfnxNQtUA@mail.gmail.com>
 <CA+2b5C3NiY7FcVbBYPKoMy4h6NbXTBY6jkJXhVU46ZorGvSBhQ@mail.gmail.com>
Message-ID: <48ad47a84e52ace8ba897247103cabab@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sat, 19 Jun 2021 00:25:38 +0000
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: Fri, 18 Jun 2021 20:00:14 -0000


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’t think this design sufficiently protects against double
> spends by the “issuer” (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’re passing
> around digital IOUs, it’s easy to make it worth it). Later 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. 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 “sent notes” 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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>> <bitcoin-dev@lists.linuxfoundation.org> 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-transactions-per-second-and-privacy-1eef8568d180
>>> https://bitcointalk.org/index.php?topic=5344020.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