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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 60729C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Jun 2020 15:01:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 4506B8579E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Jun 2020 15:01:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gvBGWISioMgh
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Jun 2020 15:01:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 01F3A855CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Jun 2020 15:01:51 +0000 (UTC)
Date: Sun, 07 Jun 2020 15:01:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1591542109;
bh=RTZhraQdHtAXyzrcOKrTs9rzf8R2wOZnLBttDpcX0EE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=I6yH/pwLwYvxbymAKPteYwkGUN/k2nOcb0NEjJGkBckOr/qxI+J0QCbv5JY+fe4S6
y6oH9533qliwbSCcfvfPFz7uUIUNGt4U8tQCrZrTrsMcCwMx1NZgAnC1IjFtiMNeW7
xklrRusjQeJI+Zz8R+UmZz9Ysg4hNrZ1w3+SVTLE=
To: Mostafa Sedaghat joo <mostafa.sedaghat@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <gNdtY-_W10fFe8vwyhQNUOCIWCtBj0G9LLUu5GQ7PYlRXejM1jwIX__TMYUhq6DDczOTQ3YYgVACOBSv6yIqx5nZ5vRbXkXPn-yjsOqi52w=@protonmail.com>
In-Reply-To: <CAJr8eKtV=W8wLkZZP9tagnL8F3jxOv8t-J9oBCFV6MrRPDmGiw@mail.gmail.com>
References: <CAJr8eKuFv7R-1HRft-hLFTSdpWUL2uOtkDtisL2+iPaEvvH_hA@mail.gmail.com>
<c_8uFmqhKnoFYLB23sjYhJlKAXU5ZoCSQ2MsSgn_OePQoJKFOqIuzMjm7vhnCzevQkAwdJextCeNjA8D-f_p__-sUFSkOFMDI5_yS7k8ZM8=@protonmail.com>
<CAJr8eKtV=W8wLkZZP9tagnL8F3jxOv8t-J9oBCFV6MrRPDmGiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stamping transaction
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, 07 Jun 2020 15:01:54 -0000
Good morning Mostafa,
> The main point of stamping transactions is decoupling transactions from t=
he block.=C2=A0
>
> Blockchain size matters
> SegWit is a good witness that shows blockchain size matters. Nowadays,=
=C2=A0Data storage is cheap and easy, but that doesn't mean it's a simple m=
atter. If you need to have a data-center to keep a copy of a blockchain, th=
en you are far from a decentralization system.=C2=A0
>
> A Solution
> Stamping=C2=A0transaction is a simple idea to keep the size of the blockc=
hain as small as possible. The question that I was looking to answer is how=
we can decouple the transaction from the blocks.
> Who cares about the transaction that happened=C2=A010 years ago. In the r=
eal world you may go to your bank and ask them to give you transaction=
=C2=A0history. But they probably have limits. They might say we just only k=
eep the last 3 months in our system.=C2=A0
Stamping transaction is not how you would be able to keep **blockchain** si=
ze low.
The reason why very old history is retained is that, if a new node is broug=
ht up, you need to prove to that node that you are in fact the correct owne=
r of the current coins.
Thus the entire history of Bitcoin is needed when starting a new node, and =
why archive nodes exist.
You might argue that banks do not do that, and that is because we want to d=
o better than banks; we know that existing currency systems have not only t=
he "official" minter, but also many "unofficial" minters (commonly called c=
ounterfeiters) which dilute the value of the currency.
It is this insistence on a full accounting of the provenance for every sato=
shi that separates Bitcoin from previous currency systems; bank fraud exist=
s, and it hides in such sloppy techniques as deleting old transaction recor=
ds.
Work has been done to have client-side validation (i.e. the owner of a coin=
keeps the entire history, and when paying, you hand over the entire histor=
y of your coin to the payee, instead of everyone validating every transacti=
on).
Look up Peter Todd for some initial work on this.
> Implementation
>
> > First off, the proposed mechanism can be made into a softfork by using =
an unspendable `scriptPubKey` with 0 output value.
> SoftFork is not possible here. Because the transaction will not be saved =
inside the block (only tx hashes). Block format needs to be changed. Theref=
ore the block will be invalid.
That greatly reduces the chances your proposal will get into Bitcoin; you w=
ould need to have very good advantages to counterbalance the tremendous ris=
k that hardforks introduce in the continuity of the coin.
Bitcoin has never gone through a hardfork that has not instead created a ne=
w cryptocurrency, so any solution that requires a hardfork is going to be u=
nlikely to be accepted by everyone.
> >=C2=A0Engineering-wise, block validation now needs to memorize the last =
N block hashes.
> I don't think we need to memorize the last N block hashes.=C2=A0 We can h=
ave something like:
> ```
> Current_Height - Height_Of(tx.stamp) <=3D N=C2=A0
> ```
...
`Height_Of()` would basically be a mapping from block hashes to block heigh=
ts, with the number of elements equal to the height of the blockchain, and =
thus continuously growing.
Thus, validation is expected to become more expensive as the blockchain gro=
ws.
Since stamped transactions have a time-to-live anyway, instead you can use =
a *set* of the most recent N block hashes.
Then you simply check if the stamp is in the set.
This creates a data structure that is constant in size (at each block, you =
remove the block from N blocks ago), which is good for validation.
> Incentives
> I think Stamping transactions have nothing to do with the incentivization=
=C2=A0mechanism.=C2=A0 Forgive me if I couldn't get your point.
A stamped tranasction has a stamp, an unstamped transaction has no stamp.
The stamped transaction is larger because of the stamp.
Larger transactions are more expensive because fees.
Thus, stamped transactions are more expensive than unstamped transactions.
Convince me why I would make *my* transaction stamped when I can just convi=
nce *everyone else* to stamp *their* transactions and use unstamped transac=
tions myself.
If you propose that all transactions must be stamped in a new version of Bi=
tcoin, then take note that users will prefer to run older versions and neve=
r upgrade to the new version that requires stamped transactions.
Why should users prefer a more expensive transaction format?
For the good of the network?
That is precisely an incentives problem: if it is so good for the network, =
then it should be good for an individual user, because the network is made =
up of individual users anyway; if individual users are not incentivized to =
use it, then that fact suggests it might not be as good for the network as =
you might think.
If you answer "the stamp can be discounted" then be aware that validating t=
he stamp is still a cost on every node, and it is that cost that we want to=
be reflected in pricing every byte in the transaction.
For instance, UTXOs are retained, potentially indefinitely, and the UTXO lo=
okup structure has to be very fast and is referred to at every transaction =
validation, so outputs (which create new UTXO entries) in SegWit are 4x mor=
e expensive than signatures, since signatures are only validated once when =
the transaction is queued to be put in the mempool.
> Mempool
> It's bad of me that I don't really know how mempool works in Bitcoin. My =
assumption is that there are some junk transactions (transactions that are =
valid but have very low or zero fees) inside the mempool. Stamping transact=
ions might help to get rid of them time to time.=C2=A0
Why would you think that stamping reduces mempool size?
If I wanted to I could just re-send the transaction with a fresh stamp.
Then the mempool usage would still be the same, and bandwidth use will incr=
ease (because the same transaction is now re-broadcast with a fresh stamp, =
and the added size of the stamps themselves).
Regards,
ZmnSCPxj
|
