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
|
Return-Path: <zhangweiwu@realss.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AFE8486
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Aug 2017 00:28:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DBDEAEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Aug 2017 00:28:24 +0000 (UTC)
Received: by mail-pg0-f50.google.com with SMTP id 63so13087113pgc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 17:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=realss-com.20150623.gappssmtp.com; s=20150623;
h=sender:from:date:to:subject:in-reply-to:message-id:references
:user-agent:mime-version;
bh=DRuV97IqeVeDTCNGqsLiTsZsmZndInbNKNVOsa4gIDw=;
b=wc/++AjfDIpRa6wb2OCAB2fRCiQg3n/5q4rrrRuaVQN59JLBZk/Ho00HCrkLDDYHlg
TuZvVK+2cwYWkh0INKWMsNUwX7fXlJ5mGm5J5BGsQsshHR+bmekgl9B/BWJNWIYATZic
2L7Gbqf5uFk7yWDcT+G+AruZrCw2+unuNC9AP82BzUJcU6Ccv4AcH4EaOWN60U0zPAkI
IjqRwSwxyuxlOVryVXcokR2GeaA+JomsHJ58tCgXMaWP0OhbQGePDjYiJIRlVddrZgrt
ZNJP0iNhKoLbpQOehzppO4u4voMgnmokt/7zQYSWOqFinwRuENAsm8V2W1RAzml7C0f1
GMqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:from:date:to:subject:in-reply-to
:message-id:references:user-agent:mime-version;
bh=DRuV97IqeVeDTCNGqsLiTsZsmZndInbNKNVOsa4gIDw=;
b=cfNcBuGvZf6iOvbXOO8zuI9H5vHkCV5yaRZp4+tnBOUoRxGLpVup89SrBRoD7pjxvK
fDRWK1z0AjxUMNY8qjweXHSDzwItc/w84r/RrpaeF2dTcNoTRxgThKjDV/IefMrhJrn9
H10G/dNXRi7SfbeisOVrWOOHGctasCcBpoAgjWKLn7RlsWHi10Y3YGk07ANh+MoN1mNI
jLKIS8nac1Iri4kJ+xy+EIuhnrT51ckGj+QZy4aiYe3LpC6tytAJb79yjGDxTBxPIOjF
NaRCse4Fc+pOK6FWc2cXVCVCdJfe86+zWKQf8rVbS+SbCFc21up7xsmirAv1mm1F7xtl
RdUA==
X-Gm-Message-State: AHYfb5hSRjn+b7a8KYo/HnmCj6cx9Uhn9QeeF4RWkPlX8XE7wz6euQCD
ZEhPH19SngwPeU8G71g=
X-Received: by 10.84.241.142 with SMTP id b14mr3502979pll.270.1503793704028;
Sat, 26 Aug 2017 17:28:24 -0700 (PDT)
Received: from [192.168.0.17] (14-200-49-1.static.tpgi.com.au. [14.200.49.1])
by smtp.gmail.com with ESMTPSA id
p2sm15874818pgr.4.2017.08.26.17.28.21
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 26 Aug 2017 17:28:23 -0700 (PDT)
Sender: Weiwu Zhang <zhangweiwu@realss.com>
From: Weiwu <a@colourful.land>
X-Google-Original-From: Weiwu <weiwu@colourful.land>
Date: Sun, 27 Aug 2017 10:27:49 +1000 (AEST)
To: bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
Message-ID: <alpine.OSX.2.21.1708270923010.933@jamess-macbook-pro.local>
References: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 27 Aug 2017 00:38:23 +0000
Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 27 Aug 2017 00:28:25 -0000
On Sat, 26 Aug 2017, Adam Tamir Shem-Tov via bitcoin-dev wrote:
> For example:
>
> A = 2.3 BTC, B=0, C=1.4. (Block 1)
>
> If A sends 2.3 BTC to B. (Block 2)
>
> And then B sends 1.5 to C. (Block 3)
>
> The pruning block will report:
>
> B = 0.8 and C=2.9.
You effecitvely want these two transactions:
A -(2.30)-> B; B -(1.5)-> C;
To be shorten to one transaction:
A -(0.8)-> B -(1.5)-> C;
For that to work a lot of changes has to be done to Bitcoin. For
simplicity of the discussion I'll assume all transactions are
standard transactions.
First, a block has to refer to the hash of the "balance sheet" (with
nonce), not the hash of the previous block. This way, a previous block
can be replaced with a smaller one without affecting the hash
reference. To add problem to this significant change, Bitcoin uses
UTXO table instead of "balance sheet". The difference is that UTXO is
indexed by transaction ID while a balance sheet is indexed by owner's
public keys. The shortening you suggested wouldn't affect the balance
sheet but would totally replace UTXOs for B and C, and probably even
A, if A has some changes left.
Second, Alice has to place a new signature on the shortened
transaction. The design challenge is how do we motivate A to do so,
since A needs to do it after "B->C", at which time Alice's business is
done and her wallet offline. Luckily, all bitcoins come from
miners. Imagine A gets her money from A', and all the way back, the
originating A" must be a miner. We just need to design a different
reward mechanism, where miners are not only rewarded by finding
blocks, but also by shortening transactions after his
expenses. Whatever new reward mechanism it may be, it will interfer
with block hash reference discussed in the previous paragraph.
Third, hash references are stablized by work. This is necessary,
otherwise a smaller block intended to replace a long one will not be
forced to maintain the same balance sheet. However, because work is
done on blocks, shortening can only happen within one block. Normally,
Bob who receives a transaction in a block, will not spend it to Carol
in the same block, because he wants 6 confirmations before being sure,
therefore, there will be little opportunity of shortening in one
block. You mentioned the idea of shortening between 1000 blocks - that
surely give a lot of opportunities to shorten a large directed
transaction graph, but you would abandon the proof of work in those
999 blocks in between.
There are three major design issue that needs to be worked out, but
almost all unique aspects of Bitcoin will be affected. Just to name a few:
- wallets need to be aware that the UTXO in it may change to some
other UTXO with the same sum value.
- nLockTime transactions are affected. Such transactions timed for
near future probably can stay by ruling that shortening can only
happen after a year; however, those timed for years to come will
find itself losing UTXO referenes (e.g. a will).
- I assumed all transactions standard, but if they are not, those who can
redeem them will lose the UTXO references to them after shortening.
I am, like you, risking proposing what is already proposed or
explaining what is already explained. The thinking around Bitcoin is a
big tome!
Regards
Weiwu Z.
|
