1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
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
|