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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <martin.schwarz@gmail.com>) id 1Z41pj-0005n0-4b
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 06:55:55 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=martin.schwarz@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z41ph-0004DE-BD
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 06:55:55 +0000
Received: by wiwd19 with SMTP id d19so48941130wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Jun 2015 23:55:47 -0700 (PDT)
X-Received: by 10.180.109.6 with SMTP id ho6mr21162942wib.58.1434264947364;
Sat, 13 Jun 2015 23:55:47 -0700 (PDT)
Received: from [10.0.0.5] (91-113-124-11.adsl.highway.telekom.at.
[91.113.124.11]) by mx.google.com with ESMTPSA id
b20sm13305818wjb.46.2015.06.13.23.55.45
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 13 Jun 2015 23:55:45 -0700 (PDT)
Message-ID: <557D2571.601@gmail.com>
Date: Sun, 14 Jun 2015 08:55:45 +0200
From: Martin Schwarz <martin.schwarz@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Pieter Wuille <pieter.wuille@gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
<CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
In-Reply-To: <CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(martin.schwarz[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z41ph-0004DE-BD
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2015 06:55:55 -0000
Pieter,
Am 13.06.2015 um 16:39 schrieb Pieter Wuille:
> We can reasonably assume that different people's wallet will tend to be distributed uniformly over several sidechains to hold their transactions (if they're not, there is no scaling benefit anyway...). That means that for an average transaction, you will need a cross-chain transfer in order to get the money to the recipient (as their wallet will usually be associated to a chain that is different from your own).
I think we should set the right incentives to invalidate these assumptions. If the fees as well as the security guarantees
on the main chain are highest and fees are dropping with the distance from the main chain on each level of side chains,
wouldn't communities with many internal transactions create their own side chain with low fees? I'd expect geographic
as well as virtual communities to be forming enjoying cheap fees on their 'local' chains and expensive but comparabily rare
'long distance' fees. One would expect geographic chains (e.g. continents) as well as virtual ones (e.g. the Open Bazaar
users' chain) to form. To save fees, a typical user would maintain a wallet in each of her communities which are loaded
and drained with rare expensive transacations, whereas daily business with many transactions is done cheaply within
each community chain. So, indeed, I would argue that side chains equipped with the right cost incentives for cross-chain
transactions would lead to a scalable and efficiently self-organizing network of side chains.
best regards,
Martin
|
