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
|
Return-Path: <thomas@thomaszander.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E9C3449B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 08:07:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 53421EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 08:07:08 +0000 (UTC)
Received: from pmx.vmail.no (localhost [127.0.0.1])
by localhost (pmx.isp.as2116.net) with SMTP id E787F440F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 10:07:06 +0200 (CEST)
Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28])
by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id A8EA7442B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 10:06:38 +0200 (CEST)
Received: from coldstorage.localnet (unknown [81.191.185.32])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.bluecom.no (Postfix) with ESMTPS id 9300D1F54B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 10:06:38 +0200 (CEST)
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 31 Jul 2015 10:06:37 +0200
Message-ID: <1550277.3yUysHbRPT@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAOG=w-vZ+5fBxpZ2bVgg_H9VD4cmSDhtkaOu4_UH3gvw-QfkEw@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<4330019.CpFTjXpmfm@coldstorage>
<CAOG=w-vZ+5fBxpZ2bVgg_H9VD4cmSDhtkaOu4_UH3gvw-QfkEw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 31 Jul 2015 08:07:09 -0000
On Thursday 30. July 2015 11.02.43 Mark Friedenbach wrote:
> It is possible for a decentralized system like bitcoin to scale via
> distribution in a way that introduces minimal trust, for example by
> probabilistic validation and distribution of fraud proofs. However changes
> to bitcoin consensus rules (mostly soft-forks) are required in order to
> make this possible.
Sounds overly complicated...
What about a much simpler solution where the miner has a CPU in a well
connected data center. Say, Amsterdam.
He runs bitcoind on there and he, in China or such, connects to it over RPC
(and ssl) to get a "block 000f00" accepted signal. Which would be 100 bytes or
so.
The miner continues to use his current setup, but with actual validation of
the blocks to completely eliminate the risk of mining on orphaned blocks and
at the same time remove most of the cost of larger-than-average bandwidth in
his country.
A slightly more complicated solution is needed to allow the miner to only send
the headers to the bitcoind instance. So he only sends a couple of kb and his
datacenter machine does the actual propagation.
If the risk of duplication becomes an issue, setup multiple propagating nodes
on different sides of the world.
Bottom line for me is that most of the innovation for making stuff better for
miners should be done in miners-specific software. Not in end-user software
like bitcoin-core.
--
Thomas Zander
|
