summaryrefslogtreecommitdiff
path: root/1d/d2f48e1e06694da7824baf22b6d87e0eb693ba
blob: 5ce2994662f886e8fc3d858364a7b861c7a09af8 (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
Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 993588EC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 May 2016 15:05:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
	[209.85.223.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD8241E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 May 2016 15:05:37 +0000 (UTC)
Received: by mail-io0-f177.google.com with SMTP id p64so57622670ioi.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 May 2016 08:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=roberts-pm.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc; bh=/1f2iJeyA/7CxveSQrI8ylshrUoqUIs9U8g0YmHorMs=;
	b=womVYTxkSVKXsmzDObJKGV/QC1CAB7/X2WPbxDusB749t5hdZ+Nn02pIqzKqZb0UnD
	p7kk6u3kf5pMWE+fRv/4IG+ocwWzQC3Vi3qqpSXVsW93c/HRckEm65FTn8Be5xKX5Rm1
	fsz3KWvLsj0FRwm9IoZLfeNImIi5RJiNE74mfYUxGPzAdnculCjF0gEmxwQbzQREOgfR
	VNLJC20uNOZuDrpvIJX2XQQ4NKmIL81BeEFv85otsrtwBG9Kbyao+aw8DIJtjjTTnu02
	BKGJE43e668rPGitVwrwINy+dFGUqwli7rgWYRJB6r37Kpczw4K+F3zJJG2oxWdPTK7n
	RCDw==
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:date
	:message-id:subject:from:to:cc;
	bh=/1f2iJeyA/7CxveSQrI8ylshrUoqUIs9U8g0YmHorMs=;
	b=QWLBDrHgp2pgt16ftqRyeBfmVYzPJLGQ/GgoWo1bnorhNIMlw5Xo8iwdceAbVc3f+D
	lh5x+LfWa4IWVA7bEGdemvpySaM7c933B7aybWKMC5PIE8rKXmtL74d62xtic+RSmOzU
	I+KTSsWTE/19SMtH5xnzFm3juFnUmReTVmY9SA+wGetpyJumPwszw18IsWZGiv4xDkSV
	Dpu+Nlre853U2e0q6mbZp18O6Ifq6inXaIlXqXjyEeWSdw9UPv+j2MJTgwn3JuObtCIJ
	4AZiFXUnul3rwjFtRRxIlJkq9/t0XGi7+cP+URJPztEwVJoBBE60QeZAvdz347JeSUir
	s1SQ==
X-Gm-Message-State: AOPr4FU7uCfiEjKpTq/gK/Zt5gBpCSR57gEAL7fNVPcygywWRYXRpUYNLEydGDynP4gJ/UxbS3I6feszVPGcMQ==
MIME-Version: 1.0
X-Received: by 10.36.230.129 with SMTP id e123mr3512217ith.92.1463756736917;
	Fri, 20 May 2016 08:05:36 -0700 (PDT)
Received: by 10.107.198.10 with HTTP; Fri, 20 May 2016 08:05:36 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
In-Reply-To: <CBBB62CD-2E30-4C9F-962E-3F340B29EDA7@xbt.hk>
References: <CAAEDBiEB_RXBjrLB8kDb52bJOwZK-arVeHA_9LyoDgAraLKHNg@mail.gmail.com>
	<CBBB62CD-2E30-4C9F-962E-3F340B29EDA7@xbt.hk>
Date: Fri, 20 May 2016 10:05:36 -0500
Message-ID: <CAAEDBiE08h=+8ntQ=mMyA0jaxj2H_6r2k0u4GdOhEkFNYEAhYQ@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=94eb2c006f6457afa90533476cff
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,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
X-Mailman-Approved-At: Fri, 20 May 2016 15:29:06 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_PRANDOM
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 20 May 2016 15:05:38 -0000

--94eb2c006f6457afa90533476cff
Content-Type: text/plain; charset=UTF-8

Good point, to be honest. Maybe there's a better way to combine the block
hashes like taking the first N bits from each block hash to produce a
single number but the direction that this is going in doesn't seem ideal.

I just asked a friend about this problem and he mentioned using the hash of
the proof of work hash as part of the number so you have to throw away a
valid POW if it doesn't give you the hash you want. I suppose its possible
to make it infinitely expensive to manipulate the number but I can't think
of anything better than that for now.

I need to sleep on this for now but let me know if anyone has any better
ideas.



On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012@xbt.hk> wrote:

> Using the hash of multiple blocks does not make it any safer. The miner of
> the last block always determines the results, by knowing the hashes of all
> previous blocks.
>
>
> == Security
>
> Pay-to-script-hash can be used to protect the details of contracts that
> use OP_PRANDOM from the prying eyes of miners. However, since there is also
> a non-zero risk that a participant in a contract may attempt to bribe a
> miner the inclusion of multiple block hashes as a source of randomness is a
> must. Every miner would effectively need to be bribed to ensure control
> over the results of the random numbers, which is already very unlikely. The
> risk approaches zero as N goes up.
>
>
>

--94eb2c006f6457afa90533476cff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Good point, to be honest. Maybe there&#39;s a better =
way to combine the block hashes like taking the first N bits from each bloc=
k hash to produce a single number but the direction that this is going in d=
oesn&#39;t seem ideal. <br><br></div><div>I just asked a friend about this =
problem and he mentioned using the hash of the proof of work hash as part o=
f the number so you have to throw away a valid POW if it doesn&#39;t give y=
ou the hash you want. I suppose its possible to make it infinitely expensiv=
e to manipulate the number but I can&#39;t think of anything better than th=
at for now.<br><br></div><div>I need to sleep on this for now but let me kn=
ow if anyone has any better ideas.<br></div><div><br><br></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, May 20, 2016 at=
 6:34 AM, Johnson Lau <span dir=3D"ltr">&lt;<a href=3D"mailto:jl2012@xbt.hk=
" target=3D"_blank">jl2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div style=3D"word-wrap:break-word"><div>Using the hash of m=
ultiple blocks does not make it any safer. The miner of the last block alwa=
ys determines the results, by knowing the hashes of all previous blocks.</d=
iv><span class=3D""><div><br></div><div><blockquote type=3D"cite"><div dir=
=3D"ltr"><p style=3D"margin-bottom:0in;line-height:100%"><br>
</p><p style=3D"margin-bottom:0in;line-height:100%">=3D=3D Security</p><p s=
tyle=3D"margin-bottom:0in;line-height:100%">Pay-to-script-hash
can be used to protect the details of contracts that use OP_PRANDOM
from the prying eyes of miners. However, since there is also a
non-zero risk that a participant in a contract may attempt to bribe a
miner the inclusion of multiple block hashes as a source of
randomness is a must. Every miner would effectively need to be bribed
to ensure control over the results of the random numbers, which is
already very unlikely. The risk approaches zero as N goes up.</p></div></bl=
ockquote></div><br></span></div></blockquote></div><br></div>

--94eb2c006f6457afa90533476cff--