summaryrefslogtreecommitdiff
path: root/54/6bccf325cdeea2da41724da67db680f30417b9
blob: 9d7af328e97e3c39451c5f7ebf7a23ff0c8bbada (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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <patrick@intersango.com>) id 1Xyd9K-00073Q-Ub
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Dec 2014 09:01:34 +0000
X-ACL-Warn: 
Received: from mail-ob0-f182.google.com ([209.85.214.182])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Xyd9J-0006N6-Ir
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Dec 2014 09:01:34 +0000
Received: by mail-ob0-f182.google.com with SMTP id wo20so1894850obc.27
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 10 Dec 2014 01:01:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type;
	bh=QPeq54sBJLBgctRBMv4i1QbOTqUkwBcprIaDMczE90k=;
	b=NNncrIiPcuEDZoTOBiDnjOpMsj6lMJIEVtbU92TKMvF+Iol72k+4OOgPL2xvYPM7bu
	/vLkCmukavka4aiw+3jj5/uSLM7/yCmGKGg9BM7ELuG6Ix/XNFTFhhKxBhnG2zVyQ+Sv
	F+dNoQriOhyTop5fzQNf1X36/9VwDDMYZx8uXdCasiTtAQHHPtvf1IjrSdmrHYKq4UWf
	KVzlMU+b7LE2lIr2+EFPHB0tvBOqIQKL+6etAzUqlClfblMrNEmd/LdwHoxleouJLeFp
	Ldn43mDmgQi0p8xocmqh9A3c01jQeKb/af4b2BCXns1Hdnt6tDAO1lFjabObiv8xM1Fo
	2AKw==
X-Gm-Message-State: ALoCoQliy1npMTPLBOq0sluIGT3B1rPjTVYyYXUME6iYRIWva8UaFibuGKTsNgCkglCfytE0DzNs
X-Received: by 10.60.99.99 with SMTP id ep3mr1813104oeb.70.1418200212384;
	Wed, 10 Dec 2014 00:30:12 -0800 (PST)
Received: from [172.20.5.189] ([12.5.152.115])
	by mx.google.com with ESMTPSA id wl6sm1717731obc.26.2014.12.10.00.30.10
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 00:30:11 -0800 (PST)
Message-ID: <54880492.9060300@intersango.com>
Date: Wed, 10 Dec 2014 02:30:10 -0600
From: patrick <patrick@intersango.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <54876653.4020403@certimix.com>
	<548769FA.5040406@bluematt.me>	<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
	<417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
In-Reply-To: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
Content-Type: multipart/alternative;
	boundary="------------090906050500020101020001"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Xyd9J-0006N6-Ir
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
 burn on parent chain
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, 10 Dec 2014 09:01:35 -0000

This is a multi-part message in MIME format.
--------------090906050500020101020001
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

The goal is to have an opportunity cost to breaking the rules.

Proof of Burn is a real cost for following the rules.

On 12/10/2014 01:35 AM, Tamas Blummer wrote:
> We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake”  and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking again an external, real world resource. 
>
> In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them.
>
> The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance.
>
> Those who want to mine the side chain will assemble  side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain.
>
> A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. 
>
> The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining” that does not need Bitcoin miner support or even consent.
>
> Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in.
>
> The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin.
>
> Tamas Blummer
> Bits of Proof
>
> 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--------------090906050500020101020001
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    The goal is to have an opportunity cost to breaking the rules.<br>
    <br>
    Proof of Burn is a real cost for following the rules.<br>
    <br>
    <div class="moz-cite-prefix">On 12/10/2014 01:35 AM, Tamas Blummer
      wrote:<br>
    </div>
    <blockquote
      cite="mid:417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com"
      type="cite">
      <pre wrap="">
We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake”  and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking again an external, real world resource. 

In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them.

The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance.

Those who want to mine the side chain will assemble  side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain.

A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. 

The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining” that does not need Bitcoin miner support or even consent.

Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in.

The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin.

Tamas Blummer
Bits of Proof

00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration &amp; more
Get technology previously reserved for billion-dollar corporations, FREE
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=164703151&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=164703151&amp;iu=/4140/ostg.clktrk</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090906050500020101020001--