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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D0F54409
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 00:17:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
[209.85.213.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E0A47C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 00:17:26 +0000 (UTC)
Received: by igr7 with SMTP id 7so26130446igr.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 17:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=4tts1ocU1u2iukw3z19+gpnNeQkFTOor945p1xhdNRc=;
b=IrrdLbtewqhm3BMcRGmBp+xeOfxMAzlpAUwa22mzu1apzJmEKOtaGpDlUtUtaQDQ1a
902gbGRCYga+rcskCLorhCW1TrFTrg4Eshqeq3fjsPH3AUspx+gCOz0CyYunNoS871Rl
6LZHx9uHz3l9DrRtxBxJYmTXj5uM1t8fYzYsc1EoWvtuB0GUrYi1amuklCDEdv5xWjWj
Nvb4O7DrLWtpzAE7HktPuqAsjOCR5f+xIRREonyef0gdKSyPCSCFXpINKDNp2psqm0nw
jzmVx5QxttxsCUOmQO1GcKb75Wawdgq8dXfFN4wH/zXpdBTRXWZTSx25jKGRMzkBFiww
NMRA==
MIME-Version: 1.0
X-Received: by 10.50.143.37 with SMTP id sb5mr10370234igb.62.1438388245772;
Fri, 31 Jul 2015 17:17:25 -0700 (PDT)
Received: by 10.107.48.212 with HTTP; Fri, 31 Jul 2015 17:17:25 -0700 (PDT)
In-Reply-To: <CAAO2FKFQjjftgEgZoDAUrMxa86KTbNzAqg+xgExTRPpGxedwRw@mail.gmail.com>
References: <CAAO2FKFQjjftgEgZoDAUrMxa86KTbNzAqg+xgExTRPpGxedwRw@mail.gmail.com>
Date: Sat, 1 Aug 2015 00:17:25 +0000
Message-ID: <CAAS2fgQL_0W0i5j0DVBY2dVtZzBj6sryycMG3Q-5KrTd1tpWaw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Hector Chu <hectorchu@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size hard fork
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: Sat, 01 Aug 2015 00:17:26 -0000
On Sat, Aug 1, 2015 at 12:05 AM, Hector Chu via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is nothing tying
> transactions to the blocks they appear in.
Transactions can be recieved or accepted in different orders by
different nodes. The purpose of the blockchain is to resolve any
potential conflicting transactions by providing a globally agreed
total ordering.
As soon as one of the forks accepts a different transaction in a
conflicting set then there will be transactions which exist on one
chain which cannot exist on the other.
One can quite easily transact in a way to intentionally produce such a
split to seperate the existance of your coins onto the seperate forks;
just as anyone would need to do to perform a reorg-and-respend attack
on a single blockchain.
Additionally, new coins will be issued, along with fees, on both
chains. These new outputs become spendable after 100 blocks, and any
transaction spending them can exist exclusively on one chain.
Also any transaction whos casual history extends from one of the above
cases can exist only on one chain. This also means that someone who
has single-chain coins (via a conflict or from coinbase outputs) can
pay small amount to many users to get their wallets to consume them
and make more of the transactions single chain only-- if they wanted
the process to happen faster.
> Miners will migrate to the bigger chain in search of higher profits due to higher volume of fees
The migration remark is a considerable oversimplification. Imagine if
I released a version of the software programmed to reassign ownership
of a million of the earliest created unmoved coins to me at block
400k, and then after that I made transaction to pay 5 coin/block in
fees. Would miners move to this chain? It pays more in fees!
|
