summaryrefslogtreecommitdiff
path: root/b2/c8444535cf3aed63106ec42115a2973b66463b
blob: 82a29836caced413bca9388c50d89f1a5e6bfd98 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@bitpay.com>) id 1XjX0E-0001JJ-Ga
	for bitcoin-development@lists.sourceforge.net;
	Wed, 29 Oct 2014 17:25:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.177 as permitted sender)
	client-ip=209.85.213.177; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f177.google.com; 
Received: from mail-ig0-f177.google.com ([209.85.213.177])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XjX0D-0004Fk-Cu
	for bitcoin-development@lists.sourceforge.net;
	Wed, 29 Oct 2014 17:25:46 +0000
Received: by mail-ig0-f177.google.com with SMTP id hl2so2603859igb.16
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 29 Oct 2014 10:25:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=82UgkFmRwlYHQqzosduzhLEwxVCPUoaAEmvdmt+WL+8=;
	b=Xsm4CEbhX6Y9yvTDzPrJZEtPyfPAR+83JVxi9SkFjsRQzWM2StqW+oBR5XYqPHTEmt
	tSixtESAkBtjuylP6ycpDpTnmNGD8jLrw2BLAY4vwjoYFThI4U6MEtcWRMxWSP92VrdK
	2YRvfcfoBZPLDcBvE4X4zO562Ji88XWXAAz+VDixjLM9t/c94rnK6n0HISR52wEJ+TQI
	BhCqaEqSyxy/IpKN1R6awYeDM2BkjI7JUz81Z2YfyPR7671k8lvvPAX1Tc4rMXRG+Baj
	uuX/7UrJiuRVMCG8MMa0gwnc2VXJuk0tYEJrpyCOyHro0VkTa2zsOmhvkHXadBsDkf3S
	n8/g==
X-Gm-Message-State: ALoCoQkr/eXt3+JHW3QoL/iSkJ2ebL7T/o/t8BDBYMdN+k4UVdYr2j8beyntZGUB5dffknsCOmsQ
X-Received: by 10.50.73.67 with SMTP id j3mr14093151igv.1.1414603539857; Wed,
	29 Oct 2014 10:25:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.156.193 with HTTP; Wed, 29 Oct 2014 10:25:19 -0700 (PDT)
In-Reply-To: <5450FAE1.5040508@certimix.com>
References: <CAE28kUS-uDbd_Br3H5BxwRm1PZFpOwLhcyyZT9b1_VfRaBC9jw@mail.gmail.com>
	<CAJHLa0PeB-DMs2zo680FRvaejV-K97k2g0Ti9pPdaNeH+gYmog@mail.gmail.com>
	<CAE28kUSPb3ZC1nJyX7H__7cAgXvOvPbZ+Tub+htGd5+tujZndg@mail.gmail.com>
	<CAJHLa0M20QjBOwhOwJWJUcPBLzmaX1uuPy-6ytvJQWLZy68aeg@mail.gmail.com>
	<CAE28kUS7cr3i-pSew6Y+xvfLEY5D1mi4oHU-GXv+jEf-i_8sVQ@mail.gmail.com>
	<CABsx9T1RPkif1+DEsOLrFfr-sE=FCs_B5C5aZzKr6HZCHw15ag@mail.gmail.com>
	<CADfmNEk40DTHDB8if_y_2i_Omoszd_BgcSxf-oS+ZcQB0tZZhg@mail.gmail.com>
	<CAAS2fgSiz-XRVQ4V+KbrTUWG4=g=WGf8c-pF4b4fFnfyU9HOqQ@mail.gmail.com>
	<CAAS2fgRjwg_XyvzHbMhmaiW85LmmsW3YiXHyhpKMHd2a03pH2Q@mail.gmail.com>
	<CAE28kUSqqcsMJArK29nG+UCiTX9buiJbQoMb30-oH-G=eFxrnQ@mail.gmail.com>
	<CAJqsvLCG2Cv=7wzDLotunEUTnAvdxVLSGrMEtkAnmdoBgONBsg@mail.gmail.com>
	<CAAS2fgR4-V10i2D=v5-ZR9rWYcBjPKyRgGvgnG3JAmPKr4x19Q@mail.gmail.com>
	<CADfmNE=2yw65aVEr=HVLWGrcQMbvpRKjraaYZehtfX=xTbdsiw@mail.gmail.com>
	<5450FAE1.5040508@certimix.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 29 Oct 2014 13:25:19 -0400
Message-ID: <CAJHLa0M5GBE69iVmFYm=uxSeVmB=iM-+9n-VW+XHg0hvDu=Ycg@mail.gmail.com>
To: Sergio Lerner <sergiolerner@certimix.com>
Content-Type: text/plain; charset=UTF-8
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 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: 1XjX0D-0004Fk-Cu
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Death by halving (pro-active proposals)
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, 29 Oct 2014 17:25:46 -0000

Seconded - IMO a key future use of the chain will be securing other
chains.  I'm interested in pursuing the merged-mining angle.

Getting chain hashes to a miner, and getting that miner payment from
the chain, is key to this.  Consider a future where there are 10,000
chains secured by one block...


On Wed, Oct 29, 2014 at 10:34 AM, Sergio Lerner
<sergiolerner@certimix.com> wrote:
> Instead of discussing what will happen when the subsidy is halved (which
> nobody really knows) maybe we can think about of what we can do to
> mitigate any damage in case something unwanted happens. Let's be proactive.
>
> For instance, any form of merged-mining (like higher frequency
> side-chains) will end-up increasing miners profit, even by a small
> margin. Then that margin can compensate miners not to turn off their
> equipment. Then we can encourage merge-mining on SHA-256, instead of
> discouraging SHA-256 alt-coins.
>
> Also we can encourage mining during the "trouble" period by creating a
> donation pool: suppose we manage to convince miners to donate 1% of
> their revenue in order to pay back to the miners for the first month
> after the reward halving. If every block pays 1% for 10 months, then
> every block during the first month of halving will earn 20% more.  Of
> course, convincing miners of this may be difficult, but not impossible.
> It could be done automatically with nLockTime freeze of transactions
> with high fees, so no TTP is necessary.
>
> So here are two proposals, any other idea?
>
> Best regards,
>  Sergio.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/