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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 24A3EC000C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jun 2021 00:55:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 19407837B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jun 2021 00:55:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.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 ekJoUS_vdEyO
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jun 2021 00:54:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
[185.70.41.104])
by smtp1.osuosl.org (Postfix) with ESMTPS id 9CD48837AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jun 2021 00:54:59 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
[51.77.79.158])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by mail-41104.protonmail.ch (Postfix) with ESMTPS id 4G6vMP2b2hz5XGKB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Jun 2021 00:54:57 +0000 (UTC)
Authentication-Results: mail-41104.protonmail.ch;
dkim=pass (1024-bit key) header.d=protonmail.com header.i=@protonmail.com
header.b="ZkIMQx6/"
Date: Sun, 20 Jun 2021 00:53:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1624150448;
bh=cTfoQ3oeu6FwwhpVWDKlLA2PYk2uiaxGRhWMSq6Ab8Q=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=ZkIMQx6/IrXSEmNDbMm0t4ok10Gt81vfJEopRsmgicv2kXe7gZJnFS9vW9xBT1FKe
DOPBmDeeLA+iEMJ/t/evoqBQreHtOE6L1blZOd8K/XcOGgYwPgloAdII6chQVODFpv
LzYMY59wSZnGV+MKALym7auW8P2PXhy4cJgeOhAg=
To: "raymo@riseup.net" <raymo@riseup.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
In-Reply-To: <bea8122aea550f1141170829aac252af@riseup.net>
References: <bea8122aea550f1141170829aac252af@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Sun, 20 Jun 2021 00:55:01 -0000
Good morning Raymo,
> 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=3D5344020.0
> Can you please read it and share your idea about it.
Guarantee Transactions (GT) being higher-fee is ***not*** assured.
Feerates are always bumpable --- the sender of a transaction only needs to =
directly contact a miner and offer a fee to take a specific transaction on =
the next block proposal, conditional on the transaction *actually* getting =
into a block.
Such "side fees" are always possible.
Indeed, the in-transaction fees are "just" a way to anonymously and atomica=
lly make that fee offer to miners --- but miners and issuers can always com=
municate directly without using Bitcoin transaction to arrange a higher fee=
for a fraudulent Main Transaction (MT).
because of this, you should really treat all unconfirmed transactions --- i=
ncluding MTs and GTs --- as potentially replaceable, i.e. RBFable.
There is no such thing as "RBF disabled", all transactions are inherently R=
BF-able due to side fees --- it is simply a matter of anonymity, atomicity,=
and ease-of-use.
---
Every offchain protocol needs *the receiver* as a signatory to any unconfir=
med transaction.
Or more strongly, the receiver **must** be a signatory --- the receiver can=
not trust an unconfirmed transaction where the spent UTXO has an alternate =
branch that does *not* have the receiver as a signatory.
See: https://zmnscpxj.github.io/offchain/safety.html
Thus, all safe offchain schemes need to use an n-of-n signing set.
The smallest n-of-n that is still useful is 2-of-2, where one participant i=
s a sender and the other is a receiver.
(1-of-1 is not useful since there is no possible receiver who can sign).
This requires Bitcoin to splinter into lots of 2-of-2 funds, each one a sov=
ereign sub-money (that is *eventually* convertible to Bitcoin), each one a =
cryptocurrency system in its own right.
However, it so happens that we have a mechanism for transferring value acro=
ss multiple cryptocurrency systems: the HTLC.
2-of-2 is also the most stable.
This is because *all* signatories of an n-of-n cryptocurrency system need t=
o be online at the same time in order for *any* of them to use the funds in=
the system.
If any one of them is offline, then the system is unusable.
With 2 participants, there is some probability that one of them is offline =
and the individual 2-of-2 system is unusable.
With 3 participants, the probability is higher (there are more participants=
that can be offline).
With 4 participants, higher still.
Thus, the most stable is to split Bitcoin into lots of little 2-of-2 system=
s, and use HTLCs to transfer funds across the little 2-of-2 systems.
Thus, Lightning Network, which splits Bitcoin into lots of little 2-of-2 cr=
yptocurrency systems (channels), and uses HTLCs to atomically transfer valu=
e across them (routing).
Of course, having larger n is better as we need to splinter Bitcoin into fe=
wer funds with larger participant sets.
And we can mitigate the offline-problem by using a two-layer system: we hav=
e a n-of-n system (n > 2) that itself splits into multiple smaller 2-of-2 s=
ystems.
That way, the Bitcoin layer is split into fewer UTXOs, reducing blockchain =
resource consumption further.
Thus, Channel Factories hosting Lightning Channels.
Regards,
ZmnSCPxj
|
