path: root/9d/106af2a352a7a01c1b178d6754582231eff9ff

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 995EB8ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 22 May 2016 13:46:19 +0000 (UTC)
X-Greylist: delayed 00:15:01 by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu
	[18.7.68.35])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC1E3FE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 22 May 2016 13:46:18 +0000 (UTC)
X-AuditID: 12074423-1abff70000006b08-01-5741b4a36407
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])
	(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by  (Symantec Messaging Gateway) with SMTP id DB.1F.27400.3A4B1475;
	Sun, 22 May 2016 09:31:15 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u4MDVEG9017056
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 22 May 2016 09:31:15 -0400
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
	[209.85.223.176]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4MDVDus012626
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 22 May 2016 09:31:14 -0400
Received: by mail-io0-f176.google.com with SMTP id t40so85553025ioi.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 22 May 2016 06:31:14 -0700 (PDT)
X-Gm-Message-State: AOPr4FX6vtrPjU4+scnrSWLVyplYKsb5DU0emtOIQzhNIignsm9Wu7ujh36hKRijXKViU0FZQUy7yIA8QjrfvQ==
X-Received: by 10.107.11.18 with SMTP id v18mr7368184ioi.184.1463923873144;
	Sun, 22 May 2016 06:31:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.42.69 with HTTP; Sun, 22 May 2016 06:30:53 -0700 (PDT)
In-Reply-To: <CAAf19WpiJDeVxi12mR8xFdjZttVYNRbsgYZzLxn2SLZDJYJHDQ@mail.gmail.com>
References: <CAAEDBiEB_RXBjrLB8kDb52bJOwZK-arVeHA_9LyoDgAraLKHNg@mail.gmail.com>
	<CBBB62CD-2E30-4C9F-962E-3F340B29EDA7@xbt.hk>
	<CAAEDBiE08h=+8ntQ=mMyA0jaxj2H_6r2k0u4GdOhEkFNYEAhYQ@mail.gmail.com>
	<CAAf19WpiJDeVxi12mR8xFdjZttVYNRbsgYZzLxn2SLZDJYJHDQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 22 May 2016 09:30:53 -0400
X-Gmail-Original-Message-ID: <CAD5xwhjOd+3FRL59EKE6n4d-RmXSjNFmXZJECDWJKfGdz9oiXw@mail.gmail.com>
Message-ID: <CAD5xwhjOd+3FRL59EKE6n4d-RmXSjNFmXZJECDWJKfGdz9oiXw@mail.gmail.com>
To: Eric Martindale <eric@ericmartindale.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113f8d266ff9f505336e56d8
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6nrrt4i2O4QftLDYum17YOjB6/f0xm
	DGCM4rJJSc3JLEst0rdL4MpoX1FfsM2j4uvHb2wNjEftuhg5OSQETCT+/LnDDGILCbQxSWyb
	otvFyAVk32WUOD3xHSuE85FJomv6JWYIZyGjxKFZ79gg2nMkPk95zghhF0vc3LKMFcTmFRCU
	ODnzCQvEWE+J/k0vmUBsToFAiU/r50IN6mGSWPd9FlCCg4NNQE7iwy9TkBoWAVWJNWtfM0HM
	TJR4tnIHG8TMAIn+q2/AyoUFtCQ6luuDmCIC1RIte1VATGYBV4kl64QhTC+J8y+yJjAKz0Jy
	ziyEDISpLrF+nhBIBbOAmsTtbVfZIWxtiWULXzMvYGRdxSibklulm5uYmVOcmqxbnJyYl5da
	pGuml5tZopeaUrqJERz+Lso7GF/2eR9iFOBgVOLh3XHHIVyINbGsuDL3EKMkB5OSKG9qt324
	EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeVxscw4V4UxIrq1KL8mFS0hwsSuK8jAwMDEIC6Ykl
	qdmpqQWpRTBZGQ4OJQne85uBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGq2wBGV5ckJhbnJkOkT/F
	aMyx5fe1tUwc26beW8skxJKXn5cqJc6bATJOAKQ0ozQPbhoohV0Mvb/hFaM40HPCvI0gVTzA
	9Ac37xXQKiagVQ+lHUBWlSQipKQaGHVLK/azzHiY5mz7YEXxwaVcLBoq11812bkwGN78aBan
	m3nzmefWcw3VdmIK2T/yV+hvTO5ulX0ZPSOVt9r9K/vzZ5lv1yjkMwrsNRKzWzlntsA8rbm1
	G76zTnuffI67Z//S8z9cXydtmmOrwDDl5vwHjO6+ulIxU7SsJUIzdSfL1zR8Pu+QoMRSnJFo
	qMVcVJwIAD6iEyo8AwAA
X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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: Sun, 22 May 2016 13:46:19 -0000

--001a113f8d266ff9f505336e56d8
Content-Type: text/plain; charset=UTF-8

nack -- not secure.

OP_PRANDOM also adds extra validation overhead on a block potentially
composed of transactions all spending an OP_PRANDOM output from all
different blocks.

I do agree that random numbers are highly desirable though.

I think it would be much better for these use cases to add OP_XOR back and
then use something like Blum's fair coin-flipping over the phone. OP_XOR
may have other uses too.

I have a write-up from a while back which does Blum's without OP_XOR using
OP_SIZE for off-chain probabilistic payments if anyone is interested. No
fork needed, but of course it is more limited and broken in a number of
ways.

(sorry to those of you seeing this twice, my first email bounced the list)

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Matthew,
>
> You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements
> Project.  It aims to achieve a similar goal.
>
> Code is in the `alpha` branch [2].
>
> [1]: https://www.elementsproject.org/elements/opcodes/
> [2]:
> https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305
>
> On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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.
>>>
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_extra">nack -- not secure.=C2=A0<br><b=
r>OP_PRANDOM also adds extra validation overhead on a block potentially com=
posed of transactions all spending an OP_PRANDOM output from all different =
blocks.<br><br>I do agree that random numbers are highly desirable though.<=
br><br>I think it would be much better for these use cases to add OP_XOR ba=
ck and then use something like Blum&#39;s fair coin-flipping over the phone=
. OP_XOR may have other uses too.<br><br>I have a write-up from a while bac=
k which does Blum&#39;s without OP_XOR using OP_SIZE for off-chain probabil=
istic payments if anyone is interested. No fork needed, but of course it is=
 more limited and broken in a number of ways.=C2=A0<br><br>(sorry to those =
of you seeing this twice, my first email bounced the list)</div><div><br><d=
iv><div><div><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRu=
bin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jerem=
yRubin" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Fri, May 20, 2016 at 2:32 PM, Eric Martin=
dale via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Matthew,<d=
iv><br></div><div>You should take a look at OP_DETERMINISTICRANDOM [1] from=
 the Elements Project.=C2=A0 It aims to achieve a similar goal.<br><br>Code=
 is in the `alpha` branch [2].</div><div><br></div><div>[1]:=C2=A0<a href=
=3D"https://www.elementsproject.org/elements/opcodes/" target=3D"_blank">ht=
tps://www.elementsproject.org/elements/opcodes/</a><br>[2]:=C2=A0<a href=3D=
"https://github.com/ElementsProject/elements/blob/alpha/src/script/interpre=
ter.cpp#L1252-L1305" target=3D"_blank">https://github.com/ElementsProject/e=
lements/blob/alpha/src/script/interpreter.cpp#L1252-L1305</a></div></div><b=
r><div class=3D"gmail_quote"><div><div><div dir=3D"ltr">On Fri, May 20, 201=
6 at 8:29 AM Matthew Roberts via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt; wrote:<br></div></div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>=
<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:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div style=3D"word-wrap:break-word"><div>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.</div><span><div>=
<br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><p style=3D"margi=
n-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></div></div><s=
pan>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</span></blockquote></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>

--001a113f8d266ff9f505336e56d8--