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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1VtAEk-0004Gi-Mv
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Dec 2013 06:04:02 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VtAEj-0007fK-5k for bitcoin-development@lists.sourceforge.net;
Wed, 18 Dec 2013 06:04:02 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Wed, 18 Dec 2013 00:03:53 -0600
id 000000000006A32E.0000000052B13AC9.00007117
Date: Wed, 18 Dec 2013 00:03:53 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20131218060353.GD3180@nl.grid.coop>
References: <20131217224130.GC3180@nl.grid.coop>
<CAAS2fgT5S8x6njU6Le9tNwR_QWnoSGzfK38VLgnFfR=p=+t72g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CAAS2fgT5S8x6njU6Le9tNwR_QWnoSGzfK38VLgnFfR=p=+t72g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: hozed.org]
X-Headers-End: 1VtAEj-0007fK-5k
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] RFC: MERGE transaction/script/process for
forked chains
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: Wed, 18 Dec 2013 06:04:02 -0000
On Tue, Dec 17, 2013 at 02:48:14PM -0800, Gregory Maxwell wrote:
> On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes <hozer@hozed.org> wrote:
> > I want to get some feedback.. I've used distributed version control
> > systems for a long time, and the most useful feature is to be able
> > to merge two different forks.
>
> We already automatically merge forks that we become aware of simply by
> pulling in all the novel non-conflicting transactions the fork
> contains and including them in our next blocks.
Now maybe this is a fatal flaw with Bitcoin's hard upper limit for number
of coins, but any miners that with good faith tried to support an islanded
bitcoin network now have generate transactions that get clobbered when
the network reconnects.
I can imagine a way to do this with some freicoin-like demurrage, which
would only impact new coinbase based on the percentage of the hashing
power that was on the other side of the fork. So if you are with the
95% of hashing power, you keep 95% of the new coins when the other 5%
shows back up from being islanded.
And this is also way more complicated than what I had first imagined
to do securely and reliably.
|
